All of lore.kernel.org
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: "Harry Yoo (Meta)" <harry@kernel.org>
Cc: "SJ Park" <sj@kernel.org>, "Johannes Weiner" <hannes@cmpxchg.org>,
	"Yosry Ahmed" <yosry@kernel.org>, "Nhat Pham" <nphamcs@gmail.com>,
	"Usama Arif" <usamaarif642@gmail.com>,
	"Chengming Zhou" <chengming.zhou@linux.dev>,
	"Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Joshua Hahn" <joshua.hahnjy@gmail.com>,
	"Kiryl Shutsemau" <kas@kernel.org>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/cgroup: ignore memory.reclaim -EAGAIN for zswap writeback test
Date: Mon, 14 Sep 2026 17:18:17 -0700	[thread overview]
Message-ID: <20260915001817.101713-1-sj@kernel.org> (raw)
In-Reply-To: <20260914-test-zswap-wb-ignore-eagain-v1-1-6fb715c22cd8@kernel.org>

Hi Harry,

On Mon, 14 Sep 2026 21:36:39 +0100 "Harry Yoo (Meta)" <harry@kernel.org> wrote:

> The zswap_writeback_enabled test fails when a write to memory.reclaim
> returns -EAGAIN, which means less than the requested amount was
> reclaimed. attempt_writeback() propagates the -EAGAIN to the caller,
> and the test case is marked as failed even when zswap writeback did
> happen.
> 
> This heavily depends on the performance of the backing swap device.
> Reclaim does not wait for writeback (on cgroup v2), does not count pages
> that are under writeback as reclaimed, and memory.reclaim gives up after
> MAX_RECLAIM_RETRIES passes without making progress. On a slow device
> where reclaim does not make any progress before writeback completes,
> a write to memory.reclaim fails.
> 
> On a VM with zswap enabled, where IO delay was injected via dm-delay,
> the success rate of the zswap writeback test drops dramatically once
> the delay reaches 11 ms: 7% failures at 10 ms and 79% failures at 11 ms,
> n = 100.
> 
> When zswap writeback is enabled, ignore -EAGAIN from memory.reclaim and
> determine pass/fail based on the zswpwb counter because that is what
> zswap_writeback_enabled actually wants to test.
> 
> With this change, the test reliably passes even on a slow swap device
> (tested up to 1000 ms delay). This makes the test resilient against
> the performance of the swap device.

Makes sense to me.

[...]
> --- a/tools/testing/selftests/cgroup/test_zswap.c
> +++ b/tools/testing/selftests/cgroup/test_zswap.c
> @@ -346,7 +346,16 @@ static int attempt_writeback(const char *cgroup, void *arg)
>  	 * it can't writeback to swap.
>  	 */
>  	ret = cg_write_numeric(cgroup, "memory.reclaim", memsize);
> -	if (!wb_enabled)
> +
> +	/*
> +	 * When writeback is enabled, memory.reclaim may still fail to reclaim
> +	 * the requested amount of memory due to a slow swap device.
> +	 * Ignore -EAGAIN here. The caller determines pass/fail based on the
> +	 * zswap writeback counter.
> +	 */
> +	if (wb_enabled && ret == -EAGAIN)
> +		ret = 0;
> +	else if (!wb_enabled)
>  		ret = (ret == -EAGAIN) ? 0 : -1;

My humble eyes were unable to easily understand the change.  Is the change
effectively same to below, and if so, would this be easier to read?

'''
@@ -344,10 +344,11 @@ static int attempt_writeback(const char *cgroup, void *arg)
         * writeback as zswap.max is 1/4 of what was needed when reclaim ran the first time.
         * If writeback is disabled, memory reclaim will fail as zswap is limited and
         * it can't writeback to swap.
+        * Even if writeback is enabled, it could return -EAGAIN due to a slow
+        * swap device.
         */
        ret = cg_write_numeric(cgroup, "memory.reclaim", memsize);
-       if (!wb_enabled)
-               ret = (ret == -EAGAIN) ? 0 : -1;
+       ret = (ret == -EAGAIN) ? 0 : -1;

 out:
        free(mem);
'''

Someone might hate the second 'ret' assignment.  But I was unable to make it
look cleaner without introducing a >80 column line.  The file already has
multiple >80 column lines and I don't really mind having a new long line,
though.


Thanks,
SJ

[...]

  reply	other threads:[~2026-09-15  0:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 20:36 [PATCH] selftests/cgroup: ignore memory.reclaim -EAGAIN for zswap writeback test Harry Yoo (Meta)
2026-09-15  0:18 ` SJ Park [this message]
2026-09-15 10:21   ` Harry Yoo
2026-09-15 14:10     ` SJ Park
2026-09-15 14:19       ` Harry Yoo
2026-09-15 17:30 ` Nhat Pham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260915001817.101713-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=harry@kernel.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mkoutny@suse.com \
    --cc=nphamcs@gmail.com \
    --cc=shuah@kernel.org \
    --cc=tj@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=yosry@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.