linux-kernel - Re: [PATCH] zswap: improve memory.zswap.writeback inheritance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dba9d7d9542d4f3d979a89f88253418c1d8a9775.camel@intelfx.name>
Date: Fri, 27 Sep 2024 01:40:04 +0200
From: Ivan Shapovalov <intelfx@...elfx.name>
To: Nhat Pham <nphamcs@...il.com>
Cc: linux-kernel@...r.kernel.org, Mike Yuan <me@...dnzj.com>, Tejun Heo	
 <tj@...nel.org>, Zefan Li <lizefan.x@...edance.com>, Johannes Weiner	
 <hannes@...xchg.org>, Michal Koutný <mkoutny@...e.com>, 
 Jonathan Corbet	 <corbet@....net>, Yosry Ahmed <yosryahmed@...gle.com>,
 Chengming Zhou	 <chengming.zhou@...ux.dev>, Michal Hocko
 <mhocko@...nel.org>, Roman Gushchin	 <roman.gushchin@...ux.dev>, Shakeel
 Butt <shakeel.butt@...ux.dev>, Muchun Song	 <muchun.song@...ux.dev>, Andrew
 Morton <akpm@...ux-foundation.org>, Chris Li	 <chrisl@...nel.org>,
 cgroups@...r.kernel.org, linux-doc@...r.kernel.org, 	linux-mm@...ck.org
Subject: Re: [PATCH] zswap: improve memory.zswap.writeback inheritance

On 2024-09-26 at 16:12 -0700, Nhat Pham wrote:
> On Thu, Sep 26, 2024 at 3:55 PM Ivan Shapovalov <intelfx@...elfx.name> wrote:
> > 
> > Improve the inheritance behavior of the `memory.zswap.writeback` cgroup
> > attribute introduced during the 6.11 cycle. Specifically, in 6.11 we
> > walk the parent cgroups until we find a _disabled_ writeback, which does
> > not allow the user to selectively enable zswap writeback while having it
> > disabled by default.
> 
> Is there an actual need for this? This is a theoretical use case I
> thought of (and raised), but I don't think anybody actually wants
> this...?

This is of course anecdata, but yes, it does solve a real use-case that
I'm having right now, as well as a bunch of my colleagues who recently
complained to me (in private) about pretty much the same use-case.

The use-case is following: it turns out that it could be beneficial for
desktop systems to run with a pretty high swappiness and zswap
writeback globally disabled, to nudge the system to compress cold pages
but not actually write them back to the disk (which would happen pretty
aggressively if it was not disabled) to reduce I/O and latencies.
However, under this setup it is sometimes needed to re-enable zswap
writeback for specific memory-heavy applications that allocate a lot of
cold pages, to "allow" the kernel to actually swap those programs out.

> 
> Besides, most people who want this can just:
> 
> 1. Enable zswap writeback on root cgroup (and all non-leaf cgroups).
> 
> 2. Disable zswap writeback on leaf cgroups on creation by default.
> 
> 3. Selectively enable zswap writeback for the leaf cgroups.
> 
> All of this is quite doable in userspace. It's not even _that_ racy -
> just do this before adding tasks etc. to the cgroup?

Well, yes, it is technically doable from userspace, just like it was
technically doable prior to commit e39925734909 to have userspace
explicitly control the entire hierarchy of writeback settings.
However it _is_ pretty painful, and the flow you described would
essentially negate any benefits of that patch (it would require
userspace to, once again, manage the entire hierarchy explicitly
without any help from the kernel).

IOWs, per the above commit I concluded that reducing pain levels for
userspace implementations was an acceptable design goal :-)

Thanks,
-- 
Ivan Shapovalov / intelfx /