Re: [PATCH v3 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled

On Thu, Jul 30, 2026 at 10:59 AM Andrew Morton
<[email protected]> wrote:
>
> On Thu, 30 Jul 2026 09:52:38 -0700 Yosry Ahmed <[email protected]> wrote:
>
> > > > >
> > > > > How does this affect users?  What behavior do they observe when it
> > > > > occurs?
> > > >
> > > > I think the first paragraph sums it up pretty well, especially the
> > > > last sentence "hotter pages with higher fault latency".
> > >
> > > How do users observe that?
> > >
> > > See, what I'm looking for here is an explanation for why we're
> > > proposing a backport.  How are our users harmed by the current code and
> > > how does this change benefit them?
> >
> > It's a potential performance regression when using zswap with memcg
> > disabled. Sorry I just realized you were looking for a high level
> > description not detailed symptoms :)
>
> Are we able to guess how significant this is?  It should have
> significant impact to justify a backport.

It depends on the workload. I think a lot of workloads may not notice
tbh, I don't think it's common to use zswap without cgroups.

> Sorry to push - I'm forever trying to train people to describe the
> userspace-visible effects so we can make these backporting decisions!
>
> And to justify those decisions to -stable maintainers
>
> And so that someone who is experiencing a slowdown in some private
> kernel branch can look at the changelog and decide whether this might
> fix it for them.

I don't think it's super important to backport, but it is also
something that we broke at some point and the fix is straightforward
and simple, so imo the risk/reward function is leaning toward
backporting it just in case. That being said, I don't feel strongly.