On 02/26/25 at 07:54am, Michal Hocko wrote:
> On Tue 25-02-25 22:22:58, Gabriel Krisman Bertazi wrote:
> > Commit 96a5c186efff ("mm/page_alloc.c: don't show protection in zone's
> > ->lowmem_reserve[] for empty zone") removes the protection of lower
> > zones from allocations targeting memory-less high zones. This had an
> > unintended impact on the pattern of reclaims because it makes the
> > high-zone-targeted allocation more likely to succeed in lower zones,
> > which adds pressure to said zones. I.e, the following corresponding
> > checks in zone_watermark_ok/zone_watermark_fast are less likely to
> > trigger:
> >
> > if (free_pages <= min + z->lowmem_reserve[highest_zoneidx])
> > return false;
> >
> > As a result, we are observing an increase in reclaim and kswapd scans,
> > due to the increased pressure. This was initially observed as increased
> > latency in filesystem operations when benchmarking with fio on a machine
> > with some memory-less zones, but it has since been associated with
> > increased contention in locks related to memory reclaim. By reverting
> > this patch, the original performance was recovered on that machine.
>
> I think it would be nice to show the memory layout on that machine (is
> there any movable or device zone)?
Yeah, printing /proc/zoneinfo and pasting it here would be helpful.
>
> Exact reclaim patterns are really hard to predict and it is little bit
> surprising the said patch has caused an increased kswapd activity
> because I would expect that there will be more reclaim with the lowmem
> reserves in place. But it is quite possible that the higher zone memory
> pressure is just tipping over and increase the lowmem pressure enough
> that it shows up.
>
> In any case 96a5c186efff seems incorrect because it assumes that the
> protection has anything to do with how higher zone is populated while
> the protection fundamentaly protects lower zone from higher zones
> allocation. Those allocations are independent on the actual memory in
> that zone.
The protection value was introduced in non-NUMA time, and later adapted
to NUMA system. While it still only reflects each zone with other zones
within one specific node. We may need take this opportunity to
reconsider it, e.g in the FALLBACK zonelists case it needs take crossing
nodes into account.
