On 2024-09-26 at 16:12 -0700, Nhat Pham wrote: > On Thu, Sep 26, 2024 at 3:55 PM Ivan Shapovalov <intelfx@xxxxxxxxxxxx> 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 /
