Linux Documentation
 help / color / mirror / Atom feed
From: Hao Jia <jiahao.kernel@gmail.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: nphamcs@gmail.com, akpm@linux-foundation.org, tj@kernel.org,
	hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@kernel.org,
	mkoutny@suse.com, chengming.zhou@linux.dev,
	muchun.song@linux.dev, roman.gushchin@linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, Hao Jia <jiahao1@lixiang.com>
Subject: Re: [PATCH v4 2/5] mm/zswap: Factor writeback loop out of shrink_worker()
Date: Mon, 29 Jun 2026 19:36:53 +0800	[thread overview]
Message-ID: <db3b3d03-61a9-1c88-4e8e-c9319b048626@gmail.com> (raw)
In-Reply-To: <CAO9r8zPVzMKFbCixxD-qgtRrkFxWVrHiZZeLc=eyTPKPVQgX4g@mail.gmail.com>



On 2026/6/27 01:09, Yosry Ahmed wrote:
>>>> /*
>>>>     * Take one step of a memcg-tree writeback walk driven by the caller's
>>>>     * iterator, and fold the result into @s, the retry bookkeeping shared
>>>>     * across steps. @memcg is the iterator's current memcg, or NULL once
>>>>     * it has wrapped around after a full pass over the tree.
>>>>     *
>>>>     * The function returns -EAGAIN to signal the caller to abort the walk
>>>>     * after encountering the following conditions MAX_RECLAIM_RETRIES times:
>>>>     * - No writeback-candidate memcgs were found in a memcg tree walk.
>>>>     * - Shrinking a writeback-candidate memcg failed.
>>>
>>> Orthogonal to this patch, but I wonder if this can be simplified. I
>>> wonder if these two conditions can be replaced with "shrinking a memcg
>>> that has zswap entries failed". The "no writeback-candidate memcgs in
>>> the tree" case seems like we should abort right away instead of
>>> retrying?
>>>
>>> Nhat, WDYT?
>>>
>>
>> Perhaps something like the following is what you had in mind? I've
>> drafted the implementation below to make it easier for Nhat to compare
>> with the previous behavior.
> 
> Hmm I think if we pursue this it should be in a separate patch or even
> outside of this series, ideally with numbers/proof that it's not
> introducing regressions to the scenario that lead to its introduction.
> 

Got it. I will temporarily leave this part out of the current patch series.

>>
>>
>>>>     *
>>>>     * Return: The number of compressed bytes written back (>= 0), or -EAGAIN
>>>>     * once the retry budget is exhausted and the caller should abort the walk.
>>>>     */
>>>> static long zswap_shrink_one(struct mem_cgroup *memcg,
>>>
>>> Nit: zswap_shrink_one_memcg()
>>>
>>> BTW, the existing writeback logic has been broken for a while now when
>>> memcg is disabled. I think we constantly hit the !memcg case and run
>>> out of retries. Not sure if your patch changes this in any way, or if
>>> you want to fix that while you're at it :)
>>
>> Yes, I'd be happy to do that. However, would it be better to submit a
>> separate fix patch or combine it with this one?
> 
> A separate patch. Feel free to send it with this series to avoid
> conflicts, but probably as patch 1 as we'll want to CC stable on it.
> 

Done, and I've just submitted the v5 patch.

[v5] 
https://lore.kernel.org/all/20260629112032.20423-1-jiahao.kernel@gmail.com

Please take a look when you have a chance. Thank you very much for your 
review!

> [..]
> 
>> /* Track progress of a memcg-tree writeback walk. */
>> struct zswap_shrink_state {
>>       int scans;
>>       int failures;
>> };
>>
>> /*
>>    * Take one step of a memcg-tree writeback walk driven by the caller's
>>    * iterator, and fold the result into @s, the retry bookkeeping shared
>>    * across steps. @memcg is the iterator's current memcg, or NULL once
>>    * it has wrapped around after a full pass over the tree.
>>    *
>>    * The function returns -EBUSY to signal the caller to abort the walk when
>>    * either of the following occurs:
>>    * - A full pass over the tree found no writeback-candidate memcg.
>>    * - Shrinking a writeback-candidate memcg failed MAX_RECLAIM_RETRIES
>> times.
>>    *
>>    * When memory cgroup is disabled, the iterator always yields NULL. All
>>    * zswap entries then live on the root list_lru, so NULL is treated as the
>>    * root memcg and shrunk directly rather than as a completed tree pass.
> 
> I think this chunk should be moved above the code returning -EBUSY
> when mem_cgroup_disabled() is true, and probably made more succinct as
> it should be obvious.

Done in v5.

> 
>>    *
>>    * Return: The number of compressed bytes written back (>= 0), or -EBUSY
>>    * when the caller should abort the walk.
>>    */
>> static long zswap_shrink_one_memcg(struct mem_cgroup *memcg,
>>                      struct zswap_shrink_state *s)
>> {
>>       bool disabled = mem_cgroup_disabled();
> 
> No need to store this in a variable AFAICT, it's a static branch and
> it's clearer to just call it directly in both call sites imo.

Done, and I've just submitted the v5 patch.

Thanks,
Hao
> 
>>       long shrunk;
>>
>>       /*
>>        * If the iterator has completed a full pass, update the shrink state
>>        * and check whether we should keep going.
>>        * With memcg disabled the iterator always yields NULL, so fall through
>>        * and shrink the root memcg directly instead.
>>        */
>>       if (!memcg && !disabled) {
>>           /*
>>            * Abort if no writeback-candidate memcgs in the last tree walk.
>>            * Otherwise reset the scans count and continue.
>>            */
>>           if (!s->scans)
>>               return -EBUSY;
>>           s->scans = 0;
>>           return 0;
>>       }
>>
>>       shrunk = shrink_memcg(memcg, NR_ZSWAP_WB_BATCH);
>>
>>       /*
>>        * There are no writeback-candidate pages in the memcg. With memcg
>>        * enabled this is not an issue as long as we can find another memcg
>>        * with pages in zswap, so skip without counting it as a candidate.
>>        * With memcg disabled the root LRU is the only target, so we should
>>        * abort if it has no writeback-candidate pages.
>>        */
>>       if (shrunk == -ENOENT)
>>           return disabled ? -EBUSY : 0;
>>       s->scans++;
>>
>>       if (shrunk <= 0 && ++s->failures == MAX_RECLAIM_RETRIES)
>>           return -EBUSY;
>>
>>       return shrunk;
>> }


  reply	other threads:[~2026-06-29 11:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  4:48 [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback Hao Jia
2026-06-18  4:48 ` [PATCH v4 1/5] mm/zswap: Extend shrink_memcg() writeback capability Hao Jia
2026-06-22 23:33   ` Yosry Ahmed
2026-06-23 13:22     ` Hao Jia
2026-06-23 18:17       ` Yosry Ahmed
2026-06-24 11:58         ` Hao Jia
2026-06-24 16:57           ` Yosry Ahmed
2026-06-25 11:31             ` Hao Jia
2026-06-18  4:48 ` [PATCH v4 2/5] mm/zswap: Factor writeback loop out of shrink_worker() Hao Jia
2026-06-22 23:36   ` Yosry Ahmed
2026-06-24 11:55     ` Hao Jia
2026-06-24 17:00       ` Yosry Ahmed
2026-06-25 11:28         ` Hao Jia
2026-06-25 17:59           ` Yosry Ahmed
2026-06-26  9:34             ` Hao Jia
2026-06-26 17:09               ` Yosry Ahmed
2026-06-29 11:36                 ` Hao Jia [this message]
2026-06-18  4:48 ` [PATCH v4 3/5] mm/zswap: Implement proactive writeback Hao Jia
2026-06-22 23:40   ` Yosry Ahmed
2026-06-18  4:48 ` [PATCH v4 4/5] mm/zswap: Add per-memcg stat for " Hao Jia
2026-06-22 23:42   ` Yosry Ahmed
2026-06-18  4:48 ` [PATCH v4 5/5] selftests/cgroup: Add tests for zswap " Hao Jia
2026-06-21  4:20 ` [PATCH v4 0/5] mm/zswap: Implement per-cgroup " Muchun Song
2026-06-22  6:08   ` Hao Jia
2026-06-22 10:04     ` Youngjun Park
2026-06-22 21:29       ` Yosry Ahmed

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=db3b3d03-61a9-1c88-4e8e-c9319b048626@gmail.com \
    --to=jiahao.kernel@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=jiahao1@lixiang.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nphamcs@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=tj@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox