Re: [PATCH] mm/zswap: use ratelimited stats flush in zswap_shrinker_count()

[Shakeel Butt <shakeel.butt@linux.dev>]

On Mon, Aug 10, 2026 at 08:09:15PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 11:27:31 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
> 
> > On Fri, Jul 10, 2026 at 9:36 AM Yunzhao Li <yunzhao@cloudflare.com> wrote:
> > >
> > > > Yeah the per-fault latency is exactly what I was looking for. Seems
> > > > like most of the faults are not faulting in the pages written back to
> > > > disk, nice.
> > >
> > > Yeah, at least for our workloads the cold entries seem to
> > > stay cold.
> > >
> > >
> > > > Would you be able to take a stab at eliminating the flushes as I
> > > > suggested above as an alternative?
> > >
> > > memcg internals are a bit out of my depth to be honest. I can
> > > definitely test a patch on our fleet though and get it verified
> > > if someone picks it up.
> > 
> > I can try to come up with a patch if you can help with testing, but it
> > won't be for a week or two. How long would it generally take to verify
> > such a patch?
> > 
> > > The ratelimited fix in mm-new is working well for us in the
> > > meantime, so it'd be great to keep that moving forward.
> > 
> > Hmm we can keep it in the pipeline for now and perhaps drop it if we
> > can get a proper fix before the next merge window. Does this sound
> > good to you?
> 
> So it doesn't seem this will be happening.
> 
> The original ratelimiting patch seems useful, is well-tested and
> well-reviewed.  I'll plan on upstreaming it in the second week of the
> merge window unless someone stops me!
> 

I agree to proceed with the patch. Since this is not exposing any api, we can
always come back to reevaluate the decision.