On 02/26/25 at 12:00pm, Michal Hocko wrote:
> On Wed 26-02-25 11:52:41, Michal Hocko wrote:
> > On Wed 26-02-25 18:00:26, Baoquan He wrote:
> > > On 02/26/25 at 07:54am, Michal Hocko wrote:
> > [...]
> > > > 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.
> >
> > Are you suggesting zone fallback list to interleave nodes? I.e.
> > numa_zonelist_order we used to have in the past and that has been
> > removed by c9bff3eebc09 ("mm, page_alloc: rip out ZONELIST_ORDER_ZONE").
Hmm, if Gabriel can provide detailed node/zone information of the
system, we can check if there's anything we can do to adjust
zone->lowmem_reserve[] to reflect its real usage and semantics. I
haven't thought of the whole zone fallback list to interleave nodes
which invovles a lot of change.
>
> Btw. has 96a5c186efff tried to fix any actual runtime problem? The
> changelog doesn't say much about that.
No, no actual problem was observed on tht. I was just trying to make
clear the semantics because I was confused by its obscure value printing
of zone->lowmem_reserve[] in /proc/zoneinfo.
I think we can merge this reverting firstly, then to investigate how to
better clarify it.
