From nobody Sat Apr 4 06:29:32 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