Re: [PATCH] mm/vmscan: clear hopeless kswapd when global direct reclaim makes progress

[Michal Hocko <mhocko@suse.com>]

On Wed 15-07-26 23:20:18, Altan Hacigumus wrote:
> On Wed, Jul 15, 2026 at 12:12 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Tue 14-07-26 19:32:04, Altan Hacigumus wrote:
> > > On Tue, Jul 14, 2026 at 4:34 AM Michal Hocko <mhocko@suse.com> wrote:
> > [...]
> > > [2] Also, there is one more condition I've been looking at, from the
> > > Sashiko review (a theoretical corner): skip the reset while tasks are
> > > throttled on pfmemalloc_wait, so that it cannot defer the hopeless
> > > escape hatch in allow_direct_reclaim().
> >
> > I would keep this a separate patch with separate reasoning. Ideally with
> > some way to trigger the behavior and prove it makes any practical
> > meaning. Theoretical corner cases might backfire in this rather
> > convoluted area.
> >
> 
> Thanks, makes sense - will drop it from this patch.
> 
> Regarding the other suggestion in the Sashiko review, I will keep that
> one in: an atomic_read() check before the atomic_xchg(), to avoid taking
> the cache line exclusive for already-zero clears in kswapd_clear_hopeless().

While this is generally a good optimization for hot paths and cache
hotlines I am not sure this is really the case for kswapd_failures. Perf
data might prove me easily wrong...
-- 
Michal Hocko
SUSE Labs