From nobody Sat Apr 4 03:19:58 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 76051360751 for ; Fri, 20 Mar 2026 20:43:07 +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=1774039388; cv=none; b=RoidCzk3/vToGg076Ld7WmfoD2t2RtztwYe8j4Owu26ZKt5xfbSTIxqtOY7pRjpehdoxd7tfNfO0G/TxpD7bFmU/3e1jKH0KKCus4uUVeoJFOUx29fOdqkkrKUj8Ye5Hs7V+FjT4vsrF4EC2mNLfZda2rwUICZtkFIcrDnM1jjs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039388; c=relaxed/simple; bh=onxeeSmwVzoB7N64JyWSHvvF13229GQf5wYZgwtu4T8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Se18FPJTmB5TR+mbzbaatV4tQe0MOlODKoef8tAj2j15ATySNqaxABoBpS9NTxq6Qe6zjhkKBAvDIhbjtofH6TzPG2z5nZXU6qWLsabX/27j/y1tQt2VjHXp7152NL8ksrKzR2H/d975i/Z2DlfTWyNIOzmcGeac+zwEAdgadpo= 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=Dy1u3OZE; 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="Dy1u3OZE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039386; 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=+VsJFp2tNWi9W0z5ic43UYrbznU9xub21G0oKpjTUlA=; b=Dy1u3OZEu1vX287/vwpnv7AfUMoTmfcPOL7AI8MNYRc/PmzT/D7dR+yFAZz/g5bJr3zIBQ BkvYD94GaysamTviOAeCi6xO7fHNuM9TnMEk/ziN+IK0zGIJXNBtHOHqxk3dmLbPOqg8PN MoCL5wb2xZ2UZOuNQkn0EPtZiWHbJWE= Received: from mx-prod-mc-01.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-691-l_GXzCzJMD-UhlKZH8gwFw-1; Fri, 20 Mar 2026 16:43:03 -0400 X-MC-Unique: l_GXzCzJMD-UhlKZH8gwFw-1 X-Mimecast-MFC-AGG-ID: l_GXzCzJMD-UhlKZH8gwFw_1774039381 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 78E78195609D; Fri, 20 Mar 2026 20:43:00 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9FAEC180075C; Fri, 20 Mar 2026 20:42:56 +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 , Li Wang Subject: [PATCH v2 1/7] memcg: Scale up vmstats flush threshold with int_sqrt(nr_cpus+2) Date: Fri, 20 Mar 2026 16:42:35 -0400 Message-ID: <20260320204241.1613861-2-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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 slower than linearly with the number of CPUs. The int_sqrt() function is a good compromise as suggested by Li Wang [1]. An extra 2 is added to make sure that we will double the threshold for a 2-core system. The increase will be slower after that. With the int_sqrt() 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. [1] https://lore.kernel.org/lkml/ab0kAE7mJkEL9kWb@redhat.com/ Suggested-by: Li Wang Signed-off-by: Waiman Long Reviewed-by: Li Wang --- mm/memcontrol.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 772bac21d155..cc1fc0f5aeea 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 * int_sqrt(nr_cpus+2)) update events. Though this + * optimization will let stats be out of sync by up to that amount. Thi= s is + * supposed to last for up to 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,14 @@ int __init mem_cgroup_init(void) =20 memcg_pn_cachep =3D KMEM_CACHE(mem_cgroup_per_node, SLAB_PANIC | SLAB_HWCACHE_ALIGN); + /* + * Scale up vmstats flush threshold with int_sqrt(nr_cpus+2). The extra + * 2 constant is to make sure that the threshold is double for a 2-core + * system. After that, it will increase by MEMCG_CHARGE_BATCH when the + * number of the CPUs reaches the next (2^n - 2) value. + */ + vmstats_flush_threshold =3D MEMCG_CHARGE_BATCH * + (int_sqrt(num_possible_cpus() + 2)); =20 return 0; } --=20 2.53.0 From nobody Sat Apr 4 03:19:58 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 1968F35DA7E for ; Fri, 20 Mar 2026 20:43:11 +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=1774039393; cv=none; b=jeyFNR/azfufWRpnTC3tpErS8LItydnIOInXOGW6d7SCnjfsyz1/QY6hDKhZ4hNaLj7HWBJ4LlwWGva+Tl1YrtDUcwKXFJNUuyTfsQVk/6hCcrwvAsh0fRblST+tj3QIb6MaXZNdDph6qLDIASwIF3DNPSXirI/Dl0A4cNU6H7w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039393; c=relaxed/simple; bh=nnUHfpWb+ToO3fSDL6WoOEh2rTTn/257I+eNth7K8N0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hIXJDPFw2NNy+7mChvyddN2A+wHJISbPkz8TkAigfoUwa7jfMins9iH/5Mj61uvSG2VIwgPBdfHa4dmcRQX/pJxsR+9E2cHGUs8CDR+cORMbNL+INLQAllAUaOLhM/1PQRQHhDxlDV/nZ8OZtIYGE+vBsqHod0xTVTEQi8iDXAA= 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=cwXy0vbl; 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="cwXy0vbl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039391; 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=n8lUtSKyFrk8YBBDo4AltLu8YBIJTZq8Ls8cEx7Gnqc=; b=cwXy0vblTzufMOIgwI9LOI+/CkG4YiWJqrJBtFJDeJ9UKeR8nj6e7x5snTtmC3nLTq1v54 htDXKUy04m1giIwsUnoGCztUu0n6XK7qBnRxh6vo5kgynNO3t6RBQgIv6xRQK+squtOvz2 UvMyllvwRX4sp1CHrVGgCwNDp1HuwfI= 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-326-HS4GhqznNiSV7KJMYjamvw-1; Fri, 20 Mar 2026 16:43:06 -0400 X-MC-Unique: HS4GhqznNiSV7KJMYjamvw-1 X-Mimecast-MFC-AGG-ID: HS4GhqznNiSV7KJMYjamvw_1774039384 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 B9A4B180034E; Fri, 20 Mar 2026 20:43:03 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B40F4180075D; Fri, 20 Mar 2026 20:43:00 +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 v2 2/7] memcg: Scale down MEMCG_CHARGE_BATCH with increase in PAGE_SIZE Date: Fri, 20 Mar 2026 16:42:36 -0400 Message-ID: <20260320204241.1613861-3-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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 hidden charges will affect the accurary of the memory.current value. This MEMCG_CHARGE_BATCH value also controls how often should the memcg vmstat values need flushing. As a result, the values reported in memory.stat cgroup control files are 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 Reviewed-by: Li Wang --- 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 Sat Apr 4 03:19:58 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 992C130AD00 for ; Fri, 20 Mar 2026 20:43: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=1774039395; cv=none; b=XeKjRK/H9xtUXFzIK31XeGHT6APNl/2T9BT5SkcFbHJddKKLhQwzFBl0tyHk4u/SXWCeT0WNTZ9rYCxnY7ySpxfoRY9/IcZg24FaAlV1QvnM0kNjVPwwCqM6ifhCP37K9gE8dmVatU3XZ60Q/aZgIYbXj+5ePxMb4hLwdAKSkm4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039395; c=relaxed/simple; bh=/Q38Q0wEw7IQ8GKq868FjCxkcXVuu/kWACpuNCOS3zM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U8POf7PVIAkJnTSuq8LJgXtiyXHfCWEkSwY3o7SUYhTTK4g/C0snkjU0yEpfp30A1r+shZdYAKKQoAd8uT5UHJPUnDIUK0tfL/Lh/7V6rsgcMWp8FKd9rqFoF62uGnoD082Hu1eYT1FEkc7HxowWclr5mylXTCkoAq8Q+OMG+d0= 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=MFgkjCjj; 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="MFgkjCjj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039393; 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=pfO//jEnSYldzUsKOHPHJUlVmZFV93Ikx/CBgNaV2RU=; b=MFgkjCjjY/Gk75yu+eVOihHTOtnsLxetAyZ1lRCQAE6paycODArgaekHIlwb1/AEgSg4DH bhl8Eqze5JLO5p2v04UgwnNoEtpl4MyK+/r2jmBMe64pi1zmiviNeId1PIHj0hOD/0GwdX 8UbubgiYvGp3NpUhbSjiYPUbFcEAg9c= 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-711-chUDSaZ6POmwEwwfCUIlXw-1; Fri, 20 Mar 2026 16:43:10 -0400 X-MC-Unique: chUDSaZ6POmwEwwfCUIlXw-1 X-Mimecast-MFC-AGG-ID: chUDSaZ6POmwEwwfCUIlXw_1774039387 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 8BD1318002CA; Fri, 20 Mar 2026 20:43:07 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3256E180075B; Fri, 20 Mar 2026 20:43:03 +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 , Li Wang Subject: [PATCH v2 3/7] selftests: memcg: Iterate pages based on the actual page size Date: Fri, 20 Mar 2026 16:42:37 -0400 Message-ID: <20260320204241.1613861-4-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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. Reviewed-by: Li Wang Signed-off-by: Waiman Long --- tools/testing/selftests/cgroup/test_memcontrol.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index a25eb097b31c..babbfad10aaf 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,10 @@ int main(int argc, char **argv) char root[PATH_MAX]; int i, proc_status; =20 + page_size =3D sysconf(_SC_PAGE_SIZE); + if (page_size <=3D 0) + page_size =3D 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 Sat Apr 4 03:19:58 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 5BFFD363086 for ; Fri, 20 Mar 2026 20:43:19 +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=1774039401; cv=none; b=jk0RPEm4A32Oo5HBtJu64PoSXKlC/52F1aVW8oafkDuoS+x7+Xh9mrh7TO9BZXuKF81SuGP7nojuqTb1iLM08lrZjDM9zTdmhXXqN9d8jq1+c0z8IUBxDTMakCNACc1qtbUmaQ6Og6QYZrel2nLLRmTyt2nMBrbgyoW5SmnO5aw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039401; c=relaxed/simple; bh=Gld23NsLrMXSYSW3eDcmAxxvCImEOQO1cTBsrXwKgjg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t2XhGuU0qWLegAFTkBWK8cLQgE51IRG4V7dQHPJ7faOFtxpR8MEq4yB/LvDaUyj07uEhSR7vKnSGKGZutx/iNDBiUDiqWLr3r8lDCrwtoT1vOR80te4CT0lulk/vCYozNt8RY460kyBhP5UvlsFyvaSQG4k3fscpkIMDkxvh6X8= 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=b5jNLna5; 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="b5jNLna5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039398; 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=sWc/eXILLPmBL1iupIXOD8iHNU0S9z1ohodxLQi1ngI=; b=b5jNLna5M1ToexpT0L0Xe4dO+EVeGaeSPD1Al0A75zAJwu2/ukFFas/CtBkiVpWPs9l2vH TIOFFUoXcVVVxPhHvrWukzl3ru7UHreB8XbK+5unstItnjav3uL6p6rjMouvN5mqZnHILW txJA9AoyOklG84KLUcDN6Mr+5PI2HXY= 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-183-hpJT8OQ1PLCcw0oAZgxppw-1; Fri, 20 Mar 2026 16:43:14 -0400 X-MC-Unique: hpJT8OQ1PLCcw0oAZgxppw-1 X-Mimecast-MFC-AGG-ID: hpJT8OQ1PLCcw0oAZgxppw_1774039391 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 32B621956055; Fri, 20 Mar 2026 20:43:11 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id F2F95180075B; Fri, 20 Mar 2026 20:43:07 +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 v2 4/7] selftests: memcg: Increase error tolerance in accordance with page size Date: Fri, 20 Mar 2026 16:42:38 -0400 Message-ID: <20260320204241.1613861-5-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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. This is likely due to the fact there may be up to MEMCG_CHARGE_BATCH pages of charge hidden in each one of the percpu memcg_stock. 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 | 3 ++- .../selftests/cgroup/test_memcontrol.c | 23 ++++++++++++++----- 2 files changed, 19 insertions(+), 7 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..2293e770e9b4 100644 --- a/tools/testing/selftests/cgroup/lib/include/cgroup_util.h +++ b/tools/testing/selftests/cgroup/lib/include/cgroup_util.h @@ -6,7 +6,8 @@ #define PAGE_SIZE 4096 #endif =20 -#define MB(x) (x << 20) +#define KB(x) ((x) << 10) +#define MB(x) ((x) << 20) =20 #define USEC_PER_SEC 1000000L #define NSEC_PER_SEC 1000000000L diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index babbfad10aaf..c078fc458def 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"); @@ -1684,6 +1687,14 @@ int main(int argc, char **argv) if (page_size <=3D 0) page_size =3D PAGE_SIZE; =20 + /* + * 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 Sat Apr 4 03:19:58 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 846273603F7 for ; Fri, 20 Mar 2026 20:43:22 +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=1774039404; cv=none; b=TjbxOdAjAhlr2XJZP4CHW3b8LpuYOQ7AWbBm1KwFepuWSx8o9r8F0YzBB438bVpwD3KXkAVY9+WtHK5Qn0kQXLEa+TgpoF+DZxAsKudJ+6mU5GGyXDo8cM7f/4/+47ZoD4t96T+7pdsrl1jtcNda0/6cVQvFKhr13OgIj9bFzBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039404; c=relaxed/simple; bh=UtguZUieBxV/7vI26O4/Kz9+NfCIO8pO0P8TNbJBYFE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rhu5YVfb1QaDTkPKQE//ekxcQAFPY25IOBnu4KpTKNHbb4ExlCecWUuB+bXr0xfVFkxKxfNlPRwew7PLB8uwpJf8g9Prx032FFIYNx1CwyDc9vUgz8fXX2a5bZFsF18JcNGr8dChyHNUUsYg70MX4LdRGaFrGI9fa+kPVGQGi8Y= 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=CPt+5TIC; 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="CPt+5TIC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039401; 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=JO4fo5puVhwmWSTN9p22d3bjrul0eBuHqiTy66++5S4=; b=CPt+5TICRJ0f/TL2X4rP/dyJPibXmALBSZcSpCThbM6CWbiGkG7oSv0xot3RnhKOPySd6n nSqoKqt3kV0xpZprbZrE5KJkkY0Vx4tRp/cxrAkXhUaBTOXx7utQ1Y53KqfWNdkHIL5ded SeZ518Gf+XIvhKI2SzUr+5N5ikHn63U= 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-120-i9oc_bP8ODSUAob25PNTlw-1; Fri, 20 Mar 2026 16:43:17 -0400 X-MC-Unique: i9oc_bP8ODSUAob25PNTlw-1 X-Mimecast-MFC-AGG-ID: i9oc_bP8ODSUAob25PNTlw_1774039395 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 DAB3918005BB; Fri, 20 Mar 2026 20:43:14 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6E3CB180075C; Fri, 20 Mar 2026 20:43:11 +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 v2 5/7] selftests: memcg: Reduce the expected swap.peak with larger page size Date: Fri, 20 Mar 2026 16:42:39 -0400 Message-ID: <20260320204241.1613861-6-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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 c078fc458def..3832ded1e47b 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 Sat Apr 4 03:19:58 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 1E46C363C6A for ; Fri, 20 Mar 2026 20:43:25 +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=1774039407; cv=none; b=UfaSiIj4KNMbdMQBvgXR6QNfmugT3+87lfyZH0Fce3TcHDxsQAvNWFL0jkRKQsYMFUx1zuyJ95lN1YztRFSDYSEQWlZtfOm8R4VHzOAuKB9qgf8KpT5L6TFCp1dGL2z/Tho+J8TWT2idwE1DAviXzQ+9KjZUlTN0dCsGZjy9I6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039407; c=relaxed/simple; bh=4kS4kT8EQrGjU2lOop+QwuSnOC0/MXNObpBVeXoFY3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T8Rs3Ej+w+l/Q7+ATLfWlzAVejEXnnl1XSJta6t43L0gD5HADZFH5XWeVt/79JfWTbso7gZ9zL1IQvSm2MuzsrSEWyktUUf27Wa8nkcZ3OG58zSXY9KoCe1YldqWGpy8Kj9ea55nSKDepxIldQ2XVM87DL90S6TnYQbCis2gFO8= 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=JTFBlMlo; 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="JTFBlMlo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039405; 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=sHG2nfg0B6suxMqU67D+nlAd3e+FK+NpiYnNJSdtKWs=; b=JTFBlMloBx3GlT+Kz+1i80Dg72RvPU3ad5Cvds5vfvOBNYq5imjzoUstmh9rG6OlLkL9Th 8oOB6P94QNGmu//gMZaTfHsXb9gqgwh5nLWvXXq7jECjuS9O5nBRx7/3b1jA8ii2s21KKF PV9qQj/pXsdeNCSqpHNdCwp+S/4F4z4= 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-553-3zwt_kK3PZmZkZVa34aB0w-1; Fri, 20 Mar 2026 16:43:20 -0400 X-MC-Unique: 3zwt_kK3PZmZkZVa34aB0w-1 X-Mimecast-MFC-AGG-ID: 3zwt_kK3PZmZkZVa34aB0w_1774039398 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 682C819560B4; Fri, 20 Mar 2026 20:43:18 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 23EE81800764; Fri, 20 Mar 2026 20:43:15 +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 v2 6/7] selftests: memcg: Don't call reclaim_until() if already in target Date: Fri, 20 Mar 2026 16:42:40 -0400 Message-ID: <20260320204241.1613861-7-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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 Reviewed-by: Li Wang --- 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 3832ded1e47b..5336be5ed2f5 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 Sat Apr 4 03:19:58 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 7018536212D for ; Fri, 20 Mar 2026 20:43:28 +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=1774039410; cv=none; b=HeILGrTg2uEBAwewX1lALdBQRT56C3mAGglm0Bw0xei6KdyLzdi+QRnoF6z6uBdZz9dTztW7dvzj4gefYVSSa+5wsCsc+mya3ogPA0zoGwo7Dfx52TyW2jtjHrvPWdEM1xcNd0e+IUcgu4cNkSFTitl6tPM6SfxyKp0bN1YSGpE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774039410; c=relaxed/simple; bh=DWcBQegSve8SZRQHLBltrNPvoMiEi11nl1pKKqMqJtI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uN3bv16vxhRb23BoqyABQg12q05MuhltCRDfn3gFP4sVvqKNppyNTEhNuqF2p5ZsrjIdireKmSF6C+LAHCjhqt+8F2EvthAJ4PmkaN1gsd2EdkbZ2AT8dOOw1r6J4CjT8lGXHAtI7oqsZBSLdCxl/XFr413c4+GqwnnslpzvSvI= 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=SbkNWGgY; 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="SbkNWGgY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774039407; 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=NNnnx0J3yeBnBNT/ZZLy4XythaRAMwcdcOOMkKfy0Ug=; b=SbkNWGgYSqXXVCKxSEnUb1lHLppWzSBO28D0qnx4MJr+8z/NqxRV5i6KKv2mB7Sg72yIxo hamRFxdmBVM7qeE8xXs1+xFDDr7hfc7f4ykuMT9e/SRR79zPGP+zpTJDple6qTRWPojASl Y8yV0MR+zMtOOK/PGpsAgR1/cMQuXxU= 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-159-QZVTQ2s2M0Stp-4wudu18w-1; Fri, 20 Mar 2026 16:43:24 -0400 X-MC-Unique: QZVTQ2s2M0Stp-4wudu18w-1 X-Mimecast-MFC-AGG-ID: QZVTQ2s2M0Stp-4wudu18w_1774039401 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 979F41800345; Fri, 20 Mar 2026 20:43:21 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.65.139]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A2A5A180075C; Fri, 20 Mar 2026 20:43:18 +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 v2 7/7] selftests: memcg: Treat failure for zeroing sock in test_memcg_sock as XFAIL Date: Fri, 20 Mar 2026 16:42:41 -0400 Message-ID: <20260320204241.1613861-8-longman@redhat.com> In-Reply-To: <20260320204241.1613861-1-longman@redhat.com> References: <20260320204241.1613861-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.93 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 | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testi= ng/selftests/cgroup/test_memcontrol.c index 5336be5ed2f5..af3e8fe4e50e 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -1486,12 +1486,21 @@ 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) { + if (sock_post > 0) + ret =3D KSFT_XFAIL; goto cleanup; + } =20 ret =3D KSFT_PASS; =20 @@ -1756,6 +1765,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