From mboxrd@z Thu Jan 1 00:00:00 1970 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 75C96946A for ; Wed, 25 Mar 2026 03:48:00 +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=1774410481; cv=none; b=d2ZbPNV3pCwB8N8KTWEV2qJsYb9P3JEcu6sDyXM88jO6XqRbkEZXL4Rz4OjMN9rParRyo+BXKu7t1nlXOb69Vr+1xRjFPivzvdZrPpzEDuXtL1DpDHx/Ds2SVD2Cqft0n1nIh9BiXkBXQ+SWxooeXwT6mepwe3KWc/60+9GzTfY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774410481; c=relaxed/simple; bh=Yej5S8iXi8AbZgFW+ajB9NiRW2qyCJsWwCuW84ZFsW8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R5DT3M15b6TWs+Dnl/+jioQqCUO7c0A7/RB1QAIIsewn29ceNm3oZnjlvgjAypI839j84xw9IGhsNATf808+/6xZwCT8/aFVJ7wjk7jg3Bwf+UOHgdrCR4DcAh1jYCHlx3CWGaK1RgH2mayVp7ROokZOREUd9mSRH4cWvibSP5w= 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=jC4fbxxl; 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="jC4fbxxl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774410479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fTWuW19SzsgMBofMGpQhLndrrAHyvaqK2jt4CAJhThs=; b=jC4fbxxlBVuutc+AgQy4JRRDAL0u/V2ACYzkutMG8i386EuZCYLzr2owtW+OIEI29zCmO0 ZVEoYtI5mASqZkmaDFbT8+/KEfSEgyJrNJqNL458/8jjbeVqrKriyOBvVEOi8f1XguAO3w DNq2xxKYtE/iwZrq2T/gHt+hsIwCC+s= 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-194-9zpRRRgTOyyAahvbGz0crA-1; Tue, 24 Mar 2026 23:47:56 -0400 X-MC-Unique: 9zpRRRgTOyyAahvbGz0crA-1 X-Mimecast-MFC-AGG-ID: 9zpRRRgTOyyAahvbGz0crA_1774410474 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 328D0195609E; Wed, 25 Mar 2026 03:47:53 +0000 (UTC) Received: from [10.22.65.192] (unknown [10.22.65.192]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E51103000223; Wed, 25 Mar 2026 03:47:48 +0000 (UTC) Message-ID: Date: Tue, 24 Mar 2026 23:47:47 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/7] selftests: memcg: Reduce the expected swap.peak with larger page size To: Li Wang Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Tejun Heo , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Shuah Khan , Mike Rapoport , 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 References: <20260320204241.1613861-1-longman@redhat.com> <20260320204241.1613861-6-longman@redhat.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 On 3/23/26 4:24 AM, Li Wang wrote: > On Fri, Mar 20, 2026 at 04:42:39PM -0400, Waiman Long wrote: >> 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/testing/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 = -1, mem_peak_fd = -1; >> >> /* 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; >> >> + /* >> + * 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 = (page_size == KB(4)) ? MB(29) : >> + ((page_size <= KB(16)) ? MB(28) : MB(27)); > Or, go with a dynamic adjustment based on page size? > > swap_peak = MB(29) - ilog2(page_size / KB(4)) * MB(1); > It is a good suggestion. I will adopt a dynamic base adjustment as suggested. Cheers, Longman