From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 288D23939B5 for ; Thu, 19 Mar 2026 17:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941947; cv=none; b=Ke1R+UyenYFT99VzsSfNIo1a/7v4iLe6yWbHgs7U2I2J4VgfCfhzqqhXGiA+fChmvOmaqdGxyFKDhRJNutU7RKPs2JIKuHuojw7TDy6HEcyIDRa8OEJ/0KJToReLiinNmd3TVn1KufqUMeBC36VONUIpXvAZ3PycFVY5w7rxWEY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941947; c=relaxed/simple; bh=dsedcvfs3WyPJKy5VxmTHtgUuAYNcPWg7HL9k5nXoXo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mbbnNJ6yLxf0VAyr4HUk3lxWqGunOvx27iLqp9NIAum8rSBFTU82Pt3crSGpogo8ILnZayR70PWM3VjEnQvuPGcneQDeAtnCmt9/zOjwGnrqThxQvZVziHhbCzSl4OMYGjef1iQP+P5k6RGLgCm4QpWFeaA0ECq6lR+aT1t8h6M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BDrnzp4Z; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BDrnzp4Z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nqbIelhKh/+RMtXT/TasUG8zStElNREsucgnnLo8/DM=; b=BDrnzp4Z2MsQ+luvXPdHAuWWN/i0/tplmvg4AXeoFwyesyr//XYjTlZuT3USsQYiRYS9zW PWO1sGWlaAtUYUUAaVsC+EhzAHAFEtqHVS1XT0eQHX6nMJ/S5tL+Uuw9+idBTX/hS+qCej n1l/zILo4x+LNk1zsG3w+VH7N0YIodk= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-523-lNQCi7DFNEiVKg0aQMKFfw-1; Thu, 19 Mar 2026 13:38:55 -0400 X-MC-Unique: lNQCi7DFNEiVKg0aQMKFfw-1 X-Mimecast-MFC-AGG-ID: lNQCi7DFNEiVKg0aQMKFfw_1773941933 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 627591956062; Thu, 19 Mar 2026 17:38:52 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D86ED30002DF; Thu, 19 Mar 2026 17:38:48 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 1/7] memcg: Scale up vmstats flush threshold with log2(nums_possible_cpus) Date: Thu, 19 Mar 2026 13:37:46 -0400 Message-ID: <20260319173752.1472864-2-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" The vmstats flush threshold currently increases linearly with the number of online CPUs. As the number of CPUs increases over time, it will become increasingly difficult to meet the threshold and update the vmstats data in a timely manner. These days, systems with hundreds of CPUs or even thousands of them are becoming more common. For example, the test_memcg_sock test of test_memcontrol always fails when running on an arm64 system with 128 CPUs. It is because the threshold is now 64*128 =3D 8192. With 4k page size, it needs changes in 32 MB of memory. It will be even worse with larger page size like 64k. To make the output of memory.stat more correct, it is better to scale up the threshold logarithmically instead of linearly with the number of CPUs. With the log2 scale, we can use the possibly larger num_possible_cpus() instead of num_online_cpus() which may change at run time. Although there is supposed to be a periodic and asynchronous flush of vmstats every 2 seconds, the actual time lag between succesive runs can actually vary quite a bit. In fact, I have seen time lags of up to 10s of seconds in some cases. So we couldn't too rely on the hope that there will be an asynchronous vmstats flush every 2 seconds. This may be something we need to look into. Signed-off-by: Waiman Long --- mm/memcontrol.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 772bac21d155..8d4ede72f05c 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -548,20 +548,20 @@ struct memcg_vmstats { * rstat update tree grow unbounded. * * 2) Flush the stats synchronously on reader side only when there are mor= e than - * (MEMCG_CHARGE_BATCH * nr_cpus) update events. Though this optimizati= on - * will let stats be out of sync by atmost (MEMCG_CHARGE_BATCH * nr_cpu= s) but - * only for 2 seconds due to (1). + * (MEMCG_CHARGE_BATCH * (ilog2(nr_cpus) + 1)) update events. Though th= is + * optimization will let stats be out of sync by up to that amount but = only + * for 2 seconds due to (1). */ static void flush_memcg_stats_dwork(struct work_struct *w); static DECLARE_DEFERRABLE_WORK(stats_flush_dwork, flush_memcg_stats_dwork); static u64 flush_last_time; +static int vmstats_flush_threshold __ro_after_init; =20 #define FLUSH_TIME (2UL*HZ) =20 static bool memcg_vmstats_needs_flush(struct memcg_vmstats *vmstats) { - return atomic_read(&vmstats->stats_updates) > - MEMCG_CHARGE_BATCH * num_online_cpus(); + return atomic_read(&vmstats->stats_updates) > vmstats_flush_threshold; } =20 static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val, @@ -5191,6 +5191,13 @@ int __init mem_cgroup_init(void) =20 memcg_pn_cachep =3D KMEM_CACHE(mem_cgroup_per_node, SLAB_PANIC | SLAB_HWCACHE_ALIGN); + /* + * Logarithmically scale up vmstats flush threshold with the number + * of CPUs. + * N.B. ilog2(1) =3D 0. + */ + vmstats_flush_threshold =3D MEMCG_CHARGE_BATCH * + (ilog2(num_possible_cpus()) + 1); =20 return 0; } --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEEEC392825 for ; Thu, 19 Mar 2026 17:39:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941949; cv=none; b=QHHg8rX4QbNcirSfCOuzFHSdFHq8/+CinMiXuqD7z7bvb91ekCimHPpRqKeYcAieNAX2P0HCepReKNsRDg1lJCkGDMe40vOzz2ZjzUtH9k8N7AfNO6lfeKgYJohBRxulgZzqo3zXCMkepPHpMxGZvgCqqgB9agtetM8fPLnkv4s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941949; c=relaxed/simple; bh=QW2o/0pD/nuSxdJjX8MhdFuXchFJ54Qmtj8E6QWwEtQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uL1x75W3Vt//ZgbhTnM0AExWsHaE7GOeVCRQHNX7+bQrF/cecnqYy59NN891ryXfwVl0QDTs/KheMA21pKOzNUl69MWyueJ2KG6prCfjf509ZIrHN8P/4FFFU4mQfCK6L4AlDgIxrJByWL1tFkLplZpIeUAc1F+TX5RtxWZStVc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Wqdi2VJT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Wqdi2VJT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v3fioxjDFRlSnWZiLdEAmcRT6TY1ObgyXmYFMHdPXDc=; b=Wqdi2VJTbKF/B6eQwBZIgGJgS+YidFxlxbUUO4sgY5xQoWSuObtCORxL4EMQcGZmJPK3TI Wu9sqGPfDIhFGaOXNgkZdbuTrzp+FhpsqHqjPdRpshaRVm0qCwmmpi1xiuFz/vMa/XaOG9 o5ibc1Cxe+15k0/UYNuGivLTSO824PM= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-cGyfdEitMnu807dx5kH8Ug-1; Thu, 19 Mar 2026 13:38:58 -0400 X-MC-Unique: cGyfdEitMnu807dx5kH8Ug-1 X-Mimecast-MFC-AGG-ID: cGyfdEitMnu807dx5kH8Ug_1773941935 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B0B611800365; Thu, 19 Mar 2026 17:38:55 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CF49330001A1; Thu, 19 Mar 2026 17:38:52 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 2/7] memcg: Scale down MEMCG_CHARGE_BATCH with increase in PAGE_SIZE Date: Thu, 19 Mar 2026 13:37:47 -0400 Message-ID: <20260319173752.1472864-3-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" For a system with 4k page size, each percpu memcg_stock can hide up to 256 kbytes of memory with the current MEMCG_CHARGE_BATCH value of 64. For another system with 64k page size, that becomes 4 Mbytes. This MEMCG_CHARGE_BATCH value also controls how often should the memcg vmstat values need flushing. As a result, the values reported in various memory cgroup control files are even less indicative of the actual memory consumption of a particular memory cgroup when the page size increases from 4k. This problem can be illustrated by running the test_memcontrol selftest. Running a 4k page size kernel on a 128-core arm64 system, the test_memcg_current_peak test which allocates a 50M anonymous memory passed. With a 64k page size kernel on the same system, however, the same test failed because the "anon" attribute of memory.stat file might report a size of 0 depending on the number of CPUs the system has. To solve this inaccurate memory stats problem, we need to scale down the amount of memory that can be hidden by reducing MEMCG_CHARGE_BATCH when the page size increases. The same user application will likely consume more memory on systems with larger page size and it is also less efficient if we scale down MEMCG_CHARGE_BATCH by too much. So I believe a good compromise is to scale down MEMCG_CHARGE_BATCH by 2 for 16k page size and by 4 with 64k page size. With that change, the test_memcg_current_peak test passed again with the modified 64k page size kernel. Signed-off-by: Waiman Long --- include/linux/memcontrol.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 70b685a85bf4..748cfd75d998 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -328,8 +328,14 @@ struct mem_cgroup { * size of first charge trial. * TODO: maybe necessary to use big numbers in big irons or dynamic based = of the * workload. + * + * There are 3 common base page sizes - 4k, 16k & 64k. In order to limit t= he + * amount of memory that can be hidden in each percpu memcg_stock for a gi= ven + * memcg, we scale down MEMCG_CHARGE_BATCH by 2 for 16k and 4 for 64k. */ -#define MEMCG_CHARGE_BATCH 64U +#define MEMCG_CHARGE_BATCH_BASE 64U +#define MEMCG_CHARGE_BATCH_SHIFT ((PAGE_SHIFT <=3D 16) ? (PAGE_SHIFT - 12)= /2 : 2) +#define MEMCG_CHARGE_BATCH (MEMCG_CHARGE_BATCH_BASE >> MEMCG_CHARGE_BATCH= _SHIFT) =20 extern struct mem_cgroup *root_mem_cgroup; =20 --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C276397E77 for ; Thu, 19 Mar 2026 17:39:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941952; cv=none; b=Fni1qkLarLLHxEmcawOZqL7Gj6C7FQQqrkLG2qsMrVWYid5+4614K7pAykYdx/cc2aKarj+SdCtDbKtgseHxHoCL3JPgYFsgXtO602O69J3JHa3MS7Vz3FFHfIhNVYbCnLYRId0UppTUmOCTRKIY/m+iQveqn10ly1r9ZMWhYnE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941952; c=relaxed/simple; bh=6fOqijcWJ1k9krh6jSFHTpRTFII3w5s4YvCh7ae5EhY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lmCpKLgsc4mHMCBMW+8dQg7a4V0TTl3Mahn2mGuioP/LVS255B9HPiDOycbEHS/PF+k5gFPPqrqaxncOx9hzW2FPYGZS+RvQYoDsq7P7ktlwyARiZgLxP/3ogVVRlGX9vm3ZJCphw8D/yhkDb8eNf8RRsuRtj5YVLPyh3Pzmx/E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YlvAWofF; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YlvAWofF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941945; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G/jvmDsSdenM6skBubfPrd0khnqGba7F4XN6aWwL11s=; b=YlvAWofFTrzZHfJnSP1BLDpx2HmGpSZ8LI9BDhMe1Ij0Z2ErOEzVbs2ogRfJ6O67W2E+bM QCJ1xHR8hPsT2g1RpstbXGUKuxduuzTHEUIFkxbsGsQGQx7sw3dEzKhBpRi+tgcyViXwdE unZ2+nqgAcKOYCGfl6yIKN8xywqraFo= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-98-vOcC0yM0NdWBC-rmiE8CEw-1; Thu, 19 Mar 2026 13:39:02 -0400 X-MC-Unique: vOcC0yM0NdWBC-rmiE8CEw-1 X-Mimecast-MFC-AGG-ID: vOcC0yM0NdWBC-rmiE8CEw_1773941939 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3593E1800464; Thu, 19 Mar 2026 17:38:59 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E99A830002DF; Thu, 19 Mar 2026 17:38:55 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 3/7] selftests: memcg: Iterate pages based on the actual page size Date: Thu, 19 Mar 2026 13:37:48 -0400 Message-ID: <20260319173752.1472864-4-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" The current test_memcontrol test fault in memory by write a value to the start of a page based on the default value of 4k page size. Micro-optimize it by using the actual system page size to do the iteration. Signed-off-by: Waiman Long Reviewed-by: Li Wang --- tools/testing/selftests/cgroup/test_memcontrol.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index a25eb097b31c..3cc8a432be91 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -25,6 +25,7 @@ =20 static bool has_localevents; static bool has_recursiveprot; +static int page_size; =20 int get_temp_fd(void) { @@ -60,7 +61,7 @@ int alloc_anon(const char *cgroup, void *arg) char *buf, *ptr; =20 buf =3D malloc(size); - for (ptr =3D buf; ptr < buf + size; ptr +=3D PAGE_SIZE) + for (ptr =3D buf; ptr < buf + size; ptr +=3D page_size) *ptr =3D 0; =20 free(buf); @@ -183,7 +184,7 @@ static int alloc_anon_50M_check(const char *cgroup, voi= d *arg) return -1; } =20 - for (ptr =3D buf; ptr < buf + size; ptr +=3D PAGE_SIZE) + for (ptr =3D buf; ptr < buf + size; ptr +=3D page_size) *ptr =3D 0; =20 current =3D cg_read_long(cgroup, "memory.current"); @@ -413,7 +414,7 @@ static int alloc_anon_noexit(const char *cgroup, void *= arg) return -1; } =20 - for (ptr =3D buf; ptr < buf + size; ptr +=3D PAGE_SIZE) + for (ptr =3D buf; ptr < buf + size; ptr +=3D page_size) *ptr =3D 0; =20 while (getppid() =3D=3D ppid) @@ -999,7 +1000,7 @@ static int alloc_anon_50M_check_swap(const char *cgrou= p, void *arg) return -1; } =20 - for (ptr =3D buf; ptr < buf + size; ptr +=3D PAGE_SIZE) + for (ptr =3D buf; ptr < buf + size; ptr +=3D page_size) *ptr =3D 0; =20 mem_current =3D cg_read_long(cgroup, "memory.current"); @@ -1679,6 +1680,7 @@ int main(int argc, char **argv) char root[PATH_MAX]; int i, proc_status; =20 + page_size =3D sysconf(_SC_PAGE_SIZE); ksft_print_header(); ksft_set_plan(ARRAY_SIZE(tests)); if (cg_find_unified_root(root, sizeof(root), NULL)) --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C13FF38E5C7 for ; Thu, 19 Mar 2026 17:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941957; cv=none; b=TxZNA2xj+Hlefqy7CcVZRXmtyKoXAO5VqnsqkvFz+W6CvyQXm0wl3ElXqM07IhxwSVr5qgCptAMNFeS8W4a6c1NI21JgT4jVyxhF958swP8V4UtQcCcnvJb/q4i5Y1Lza5B0MyRWuI8zFW2NRHG3ouxHenK9Qhq1UCobskJ85tk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941957; c=relaxed/simple; bh=1YF3Po/hWcN908df/JjlPnlSCsp5XMq/OPhqEQrLq8U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Qr7/AZ04tjO0fhKTYEKCGQiK1k4ICIJNfR8iUIXpqem7gL+JQgm0bdbMtMQsgDq2Et2aB3HEpDQdoIk7zHd/pVct9tagthZfel27zZG73HU8mmmR9SqSddwsnKrsr7Xpgo3+cyyGPySOHnJJjMS7MkqLYcm101Wq/W7zHdJZiPg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OOO4ZMVF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OOO4ZMVF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941948; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dNJ6Lq8/T1XPjKqwxrWp5F2Bbd2jRHO9QNryMAsqUQU=; b=OOO4ZMVFhScpPzOoYSLfj5bt6vGenhlvUgWfQxjfJFZv017K5Yeju1eoeVBigYZIWimkc/ GOlCONI0Z19z89z1VTvYi2Zk+AHs9siBon2DXVomLrSypIfS1pe7Nt4S6PPFF9tmHvPuAX eCiwsuI7N4qUoTSgpWqy5hydDF54W1E= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-31Ev_X7TNdGagwe5I4LhcA-1; Thu, 19 Mar 2026 13:39:05 -0400 X-MC-Unique: 31Ev_X7TNdGagwe5I4LhcA-1 X-Mimecast-MFC-AGG-ID: 31Ev_X7TNdGagwe5I4LhcA_1773941942 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8A0481944F05; Thu, 19 Mar 2026 17:39:02 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7068D30001A1; Thu, 19 Mar 2026 17:38:59 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 4/7] selftests: memcg: Increase error tolerance in accordance with page size Date: Thu, 19 Mar 2026 13:37:49 -0400 Message-ID: <20260319173752.1472864-5-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" It was found that some of the tests in test_memcontrol can fail more readily if system page size is larger than 4k. It is because the actual memory.current value deviates more from the expected value with larger page size. To avoid this failure, the error tolerance is now increased in accordance to the current system page size value. The page size scale factor is set to 2 for 64k page and 1 for 16k page. Changes are made in alloc_pagecache_max_30M(), test_memcg_protection() and alloc_anon_50M_check_swap() to increase the error tolerance for memory.current for larger page size. The current set of values are chosen to ensure that the relevant test_memcontrol tests no longer have any test failure in a 100 repeated run of test_memcontrol with a 4k/16k/64k page size kernels on an arm64 system. Signed-off-by: Waiman Long --- .../cgroup/lib/include/cgroup_util.h | 1 + .../selftests/cgroup/test_memcontrol.c | 23 ++++++++++++++----- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/cgroup/lib/include/cgroup_util.h b/too= ls/testing/selftests/cgroup/lib/include/cgroup_util.h index 77f386dab5e8..c25228a78b8b 100644 --- a/tools/testing/selftests/cgroup/lib/include/cgroup_util.h +++ b/tools/testing/selftests/cgroup/lib/include/cgroup_util.h @@ -6,6 +6,7 @@ #define PAGE_SIZE 4096 #endif =20 +#define KB(x) (x << 10) #define MB(x) (x << 20) =20 #define USEC_PER_SEC 1000000L diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index 3cc8a432be91..2c3a838536ae 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -26,6 +26,7 @@ static bool has_localevents; static bool has_recursiveprot; static int page_size; +static int pscale_factor; /* Page size scale factor */ =20 int get_temp_fd(void) { @@ -571,16 +572,17 @@ static int test_memcg_protection(const char *root, bo= ol min) if (cg_run(parent[2], alloc_anon, (void *)MB(148))) goto cleanup; =20 - if (!values_close(cg_read_long(parent[1], "memory.current"), MB(50), 3)) + if (!values_close(cg_read_long(parent[1], "memory.current"), MB(50), + 3 + (min ? 0 : 4) * pscale_factor)) goto cleanup; =20 for (i =3D 0; i < ARRAY_SIZE(children); i++) c[i] =3D cg_read_long(children[i], "memory.current"); =20 - if (!values_close(c[0], MB(29), 15)) + if (!values_close(c[0], MB(29), 15 + 3 * pscale_factor)) goto cleanup; =20 - if (!values_close(c[1], MB(21), 20)) + if (!values_close(c[1], MB(21), 20 + pscale_factor)) goto cleanup; =20 if (c[3] !=3D 0) @@ -596,7 +598,8 @@ static int test_memcg_protection(const char *root, bool= min) } =20 current =3D min ? MB(50) : MB(30); - if (!values_close(cg_read_long(parent[1], "memory.current"), current, 3)) + if (!values_close(cg_read_long(parent[1], "memory.current"), current, + 9 + (min ? 0 : 6) * pscale_factor)) goto cleanup; =20 if (!reclaim_until(children[0], MB(10))) @@ -684,7 +687,7 @@ static int alloc_pagecache_max_30M(const char *cgroup, = void *arg) goto cleanup; =20 current =3D cg_read_long(cgroup, "memory.current"); - if (!values_close(current, MB(30), 5)) + if (!values_close(current, MB(30), 5 + (pscale_factor ? 2 : 0))) goto cleanup; =20 ret =3D 0; @@ -1004,7 +1007,7 @@ static int alloc_anon_50M_check_swap(const char *cgro= up, void *arg) *ptr =3D 0; =20 mem_current =3D cg_read_long(cgroup, "memory.current"); - if (!mem_current || !values_close(mem_current, mem_max, 3)) + if (!mem_current || !values_close(mem_current, mem_max, 6 + pscale_factor= )) goto cleanup; =20 swap_current =3D cg_read_long(cgroup, "memory.swap.current"); @@ -1681,6 +1684,14 @@ int main(int argc, char **argv) int i, proc_status; =20 page_size =3D sysconf(_SC_PAGE_SIZE); + /* + * It is found that the actual memory.current value can deviate more + * from the expected value with larger page size. So error tolerance + * will have to be increased a bit more for larger page size. + */ + if (page_size > KB(4)) + pscale_factor =3D (page_size >=3D KB(64)) ? 2 : 1; + ksft_print_header(); ksft_set_plan(ARRAY_SIZE(tests)); if (cg_find_unified_root(root, sizeof(root), NULL)) --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B54DF3E8C60 for ; Thu, 19 Mar 2026 17:39:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941962; cv=none; b=UTRqcd6PcJR9n948mwHw685s0lD+EUGqbDclNk2BaqtMOvqN18xJscqaCzVy4oc0BL14rzxvkNZswc7D2MrB52GpulBTYUYnTdT+1xl40ApsJ23EBFdGry0KlcFqkq4z98CcsznXCMCl+M+mj/CL/joLmDj1sYiW7EaS4Nj8d4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941962; c=relaxed/simple; bh=nxAjAjAgP+lCo3v+SKq8jvMRzDUk+BwOWF50IkkWiZc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fotom8vhK25a+yHFTkM+c04gL3cdJTZcqoI1kOZj7L2bhe6o5Jkp4vFVnUIXRl192rnRjSV4J4y175hZzFqvqc0az7MXYkImya1ppSj5o1XCxltJi2+V/JVbh6hzvxv4RxJwompxAigF2eQJZfRXXpbwqW/g9CDWFDa+BZtbcTA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=c74EOEhF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="c74EOEhF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941953; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zkUulf/dklOOtLe7ygalmkfZiPOwnIaF4ZwIQQPoF50=; b=c74EOEhFY26gD/pSfhuOPbFpMlWZGIU9DEFs9oQqyYPjVa1kLBDC4Q/3ozg8UIi60L3/QH Q61lj+Lfu05K8EjEeVe49rXJMcDm4kcdLREAZ+0mmvfCtNh2lIBKw2xf51vIUZ0jZLymzV pHqKQNfbRH21VTryPOgv+5JnsxWb50c= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-HIcTViPWP_quBmhI6xe-QA-1; Thu, 19 Mar 2026 13:39:08 -0400 X-MC-Unique: HIcTViPWP_quBmhI6xe-QA-1 X-Mimecast-MFC-AGG-ID: HIcTViPWP_quBmhI6xe-QA_1773941946 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CB044195607B; Thu, 19 Mar 2026 17:39:05 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C4BCD30001A1; Thu, 19 Mar 2026 17:39:02 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 5/7] selftests: memcg: Reduce the expected swap.peak with larger page size Date: Thu, 19 Mar 2026 13:37:50 -0400 Message-ID: <20260319173752.1472864-6-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" When running the test_memcg_swap_max_peak test which sets swap.max to 30M on an arm64 system with 64k page size, the test failed as the swap.peak could only reach up only to 27,328,512 bytes (about 25.45 MB which is lower than the expected 29M) before the allocating task got oom-killed. It is likely due to the fact that it takes longer to write out a larger page to swap and hence a lower swap.peak is being reached. Setting memory.high to 29M to throttle memory allocation when nearing memory.max helps, but it still could only reach up to 29,032,448 bytes (about 27.04M). As a result, we have to reduce the expected swap.peak with larger page size. Now swap.peak is expected to reach only 27M with 64k page, 29M with 4k page and 28M with 16k page. Signed-off-by: Waiman Long --- .../selftests/cgroup/test_memcontrol.c | 26 ++++++++++++++++--- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index 2c3a838536ae..4f12d4b4f9f8 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -1032,6 +1032,7 @@ static int test_memcg_swap_max_peak(const char *root) char *memcg; long max, peak; struct stat ss; + long swap_peak; int swap_peak_fd =3D -1, mem_peak_fd =3D -1; =20 /* any non-empty string resets */ @@ -1119,6 +1120,23 @@ static int test_memcg_swap_max_peak(const char *root) if (cg_write(memcg, "memory.max", "30M")) goto cleanup; =20 + /* + * The swap.peak that can be reached will depend on the system page + * size. With larger page size (e.g. 64k), it takes more time to write + * the anonymous memory page to swap and so the peak reached will be + * lower before the memory allocation process get oom-killed. One way + * to allow the swap.peak to go higher is to throttle memory allocation + * by setting memory.high to, say, 29M to give more time to swap out the + * memory before oom-kill. This is still not enough for it to reach + * 29M reachable with 4k page. So we still need to reduce the expected + * swap.peak accordingly. + */ + swap_peak =3D (page_size =3D=3D KB(4)) ? MB(29) : + ((page_size <=3D KB(16)) ? MB(28) : MB(27)); + + if (cg_write(memcg, "memory.high", "29M")) + goto cleanup; + /* Should be killed by OOM killer */ if (!cg_run(memcg, alloc_anon, (void *)MB(100))) goto cleanup; @@ -1134,7 +1152,7 @@ static int test_memcg_swap_max_peak(const char *root) goto cleanup; =20 peak =3D cg_read_long(memcg, "memory.swap.peak"); - if (peak < MB(29)) + if (peak < swap_peak) goto cleanup; =20 peak =3D cg_read_long_fd(mem_peak_fd); @@ -1142,7 +1160,7 @@ static int test_memcg_swap_max_peak(const char *root) goto cleanup; =20 peak =3D cg_read_long_fd(swap_peak_fd); - if (peak < MB(29)) + if (peak < swap_peak) goto cleanup; =20 /* @@ -1181,7 +1199,7 @@ static int test_memcg_swap_max_peak(const char *root) if (cg_read_long(memcg, "memory.peak") < MB(29)) goto cleanup; =20 - if (cg_read_long(memcg, "memory.swap.peak") < MB(29)) + if (cg_read_long(memcg, "memory.swap.peak") < swap_peak) goto cleanup; =20 if (cg_run(memcg, alloc_anon_50M_check_swap, (void *)MB(30))) @@ -1196,7 +1214,7 @@ static int test_memcg_swap_max_peak(const char *root) goto cleanup; =20 peak =3D cg_read_long(memcg, "memory.swap.peak"); - if (peak < MB(29)) + if (peak < swap_peak) goto cleanup; =20 peak =3D cg_read_long_fd(mem_peak_fd); --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 714FC3CF673 for ; Thu, 19 Mar 2026 17:39:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941962; cv=none; b=R4wvM5bnoIcH9zUWs8ldl4PkMe+ylCJtnEcJ018IQHDn4TAfXP2YGsEXNbcwwOF8pQaRr/OnDov/arfxm2e5f7QqB9NLV39tEHsGpKlNbrkNx263fuZmsaGpEUqqRYszWky/+A5di2qTwgaHAPeZakTO5XdYVDze9HXpcHWtAD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941962; c=relaxed/simple; bh=mInYEpsHgQ0sSu1v8PF2dLL2Vd4hkmR1DRzwhCUTikg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F5ye7Dem2AS3UT7NFsiu0KggEmHdS498q3ji3FbhOpHDT3q0fcVWpDJHY/6aDCSWrEEth8wIcu5WNRs/ZUHKSCpn8STO7QjIQF7F62qNOUYkbHxJmULJ6zOIndEJVXmQbPQMCEkw09RzNsU7nS5bfxZLpfr2rox85SenmY0iOEU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OQN4Isv6; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OQN4Isv6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=08dKphVfSTLtdpNxVh0zM+lKvwtD8+RfKPGuI2AqB10=; b=OQN4Isv6yBH/AT9VGIrnfAiITDv2oCJNiNU/s1tt64KsSU7mCgVb4OVUl+Y70aBZsjqSe6 qKv1rwzOGoy/M2WgggxfXmV0z9J1Y403MJGRBE/I4bqDt9Ro+6TYwxNaE+UqRmtjB1ziZC 0r6CAykmyPc4sx8LNhj28OKOSvfY36g= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-212-FclM--_NPeiuVWdz8HznfA-1; Thu, 19 Mar 2026 13:39:12 -0400 X-MC-Unique: FclM--_NPeiuVWdz8HznfA-1 X-Mimecast-MFC-AGG-ID: FclM--_NPeiuVWdz8HznfA_1773941949 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 525641955F6A; Thu, 19 Mar 2026 17:39:09 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0FE4130001A1; Thu, 19 Mar 2026 17:39:05 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 6/7] selftests: memcg: Don't call reclaim_until() if already in target Date: Thu, 19 Mar 2026 13:37:51 -0400 Message-ID: <20260319173752.1472864-7-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" Near the end of test_memcg_protection(), reclaim_until() is called to reduce memory.current of children[0] to 10M. It was found that with larger page size (e.g. 64k) the various memory cgroups in test_memcg_protection() would deviate further from the expected values especially for the test_memcg_low test. As a result, children[0] might have reached the target already without reclamation. The will cause the reclaim_until() function to report failure as no reclamation is needed. Avoid this unexpected failure by skipping the reclaim_until() call if memory.current of children[0] has already reached the target size for kernel with non-4k page size. Signed-off-by: Waiman Long --- tools/testing/selftests/cgroup/test_memcontrol.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index 4f12d4b4f9f8..0ef09bafa68c 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -490,6 +490,7 @@ static int test_memcg_protection(const char *root, bool= min) long current; int i, attempts; int fd; + bool do_reclaim; =20 fd =3D get_temp_fd(); if (fd < 0) @@ -602,7 +603,15 @@ static int test_memcg_protection(const char *root, boo= l min) 9 + (min ? 0 : 6) * pscale_factor)) goto cleanup; =20 - if (!reclaim_until(children[0], MB(10))) + /* + * With larger page size, it is possible that memory.current of + * children[0] is close to 10M. Skip the reclaim_until() call if + * that is the case. + */ + current =3D cg_read_long(children[0], "memory.current"); + do_reclaim =3D (page_size =3D=3D KB(4)) || + ((current > MB(10)) && !values_close(current, MB(10), 3)); + if (do_reclaim && !reclaim_until(children[0], MB(10))) goto cleanup; =20 if (min) { --=20 2.53.0 From nobody Mon Apr 6 10:31:26 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 435073EF0C7 for ; Thu, 19 Mar 2026 17:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941967; cv=none; b=BL3XJErmhlAYp2H1O3qHIU/ybhgtwsegySwpMV5hpZHX5JjIX6h1+qZXCvEUVwF85PNsg049WQRxqhDj2qDrSJ3CMpoOki3w0ZU4ArNCVEQLejXgONQ/7emzlhbnuGVnJYtFcWQrJadEf1wHwY7bcT23OfOKsLJ5LquN8rk6x0I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773941967; c=relaxed/simple; bh=wFAtlTmn43+vpFnlZmsivMZE1tzHU7BC53jPKGhv5C0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WMgUuXyye8uUTZNaDm8h+drC3pKh0isy3l19ANcKGvr/yVg0ox+d8VByuXwP6cRcIh0oJf3rjERUCCj9q9uMZNrxT8Zv3OcjGsEQXua5seGeJjeZmQegh7ZUur5C1MTvW8ZIDChYq6t5cvBWpDIOmAwAZ8DoloO0ULhGAtXZKPI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aLalJSfs; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aLalJSfs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773941959; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y8AJoJFhemnk1DLT2xYvQamPJ/h63aubGqhq+ZDBiKQ=; b=aLalJSfsmaq/XAgufrfop47XPy6TGfAHnjZL+TUpl2wzWuhlEqa2WcpwTyfCZ4Bz2eZSLy QFLSAD3j3cpYpzN2wmgHes4/zyYRg2j57BklIiMUV1H5GQfudrPS45G3d+alOqIBK3mc+l WVRRbA/YmB5u9gU8ddvVix3DgoP3aFw= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-45-N4MyzdgGOh-xRtock0apmA-1; Thu, 19 Mar 2026 13:39:15 -0400 X-MC-Unique: N4MyzdgGOh-xRtock0apmA-1 X-Mimecast-MFC-AGG-ID: N4MyzdgGOh-xRtock0apmA_1773941953 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D731818005BB; Thu, 19 Mar 2026 17:39:12 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.194]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A7CE330001A1; Thu, 19 Mar 2026 17:39:09 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan , Mike Rapoport Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Sean Christopherson , James Houghton , Sebastian Chlad , Guopeng Zhang , Li Wang , Waiman Long Subject: [PATCH 7/7] selftests: memcg: Treat failure for zeroing sock in test_memcg_sock as XFAIL Date: Thu, 19 Mar 2026 13:37:52 -0400 Message-ID: <20260319173752.1472864-8-longman@redhat.com> In-Reply-To: <20260319173752.1472864-1-longman@redhat.com> References: <20260319173752.1472864-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" Although there is supposed to be a periodic and asynchronous flush of stats every 2 seconds, the actual time lag between succesive runs can actually vary quite a bit. In fact, I have seen time lag of up to 10s of seconds in some cases. At the end of test_memcg_sock, it waits up to 3 seconds for the "sock" attribute of memory.stat to go back down to 0. Obviously it may occasionally fail especially when the kernel has large page size (e.g. 64k). Treat this failure as an expected failure (XFAIL) to distinguish it from the other failure cases. Signed-off-by: Waiman Long --- tools/testing/selftests/cgroup/test_memcontrol.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index 0ef09bafa68c..9206da51ac83 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -1486,12 +1486,20 @@ static int test_memcg_sock(const char *root) * Poll memory.stat for up to 3 seconds (~FLUSH_TIME plus some * scheduling slack) and require that the "sock " counter * eventually drops to zero. + * + * The actual run-to-run elapse time between consecutive run + * of asynchronous memcg rstat flush may varies quite a bit. + * So the 3 seconds wait time may not be enough for the "sock" + * counter to go down to 0. Treat it as a XFAIL instead of + * a FAIL. */ sock_post =3D cg_read_key_long_poll(memcg, "memory.stat", "sock ", 0, MEMCG_SOCKSTAT_WAIT_RETRIES, DEFAULT_WAIT_INTERVAL_US); - if (sock_post) + if (sock_post) { + ret =3D KSFT_XFAIL; goto cleanup; + } =20 ret =3D KSFT_PASS; =20 @@ -1753,6 +1761,9 @@ int main(int argc, char **argv) case KSFT_SKIP: ksft_test_result_skip("%s\n", tests[i].name); break; + case KSFT_XFAIL: + ksft_test_result_xfail("%s\n", tests[i].name); + break; default: ksft_test_result_fail("%s\n", tests[i].name); break; --=20 2.53.0