Re: [PATCH]: Clean up of __alloc_pages

Martin J. Bligh
2005-10-04T16:10:48Z

--Ray Bryant <raybry@mpdtxmail.amd.com> wrote (on Tuesday, October 04, 2005 11:26:52 -0500):

> On Tuesday 04 October 2005 08:27, Andi Kleen wrote:
>> Rohit Seth <rohit.seth@intel.com> writes:
>> > I think conceptually this ask for a new flag __GFP_NODEONLY that
>> > indicate allocations to come from current node only.
>> >
>> > This definitely though means I will need to separate out the allocation
>> > from pcp patch (as Nick suggested earlier).
>>
>> This reminds me - the current logic is currently a bit suboptimal on
>> many NUMA systems. Often it would be better to be a bit more
>> aggressive at freeing memory (maybe do a very low overhead light try to
>> free pages) in the first node before falling back to other nodes. What
>> right now happens is that when you have even minor memory pressure
>> because e.g. you node is filled up with disk cache the local memory
>> affinity doesn't work too well anymore.
>>
>> -Andi
>>
> That's exactly what Martin Hick's additions to __alloc_pages() were trying to
> achieve. However, we've never figured out how to make the "very low
> overhead light try to free pages" thing work with low enough overhead that it
> can be left on all of the time. As soon as we make this the least bit more
> expensive, then this hurts those workloads (file servers being one example)
> who don't care about local, but who need the fastest possible allocations.
>
> This problem is often a showstopper on larger NUMA systems, at least for HPC
> type applications, where the inability to guarantee local storage allocation
> when it is requested can make the application run significantly slower.

Can we not do some migration / more targeted pressure balancing in kswapd?
Ie if we had a constant measure of per-node pressure, we could notice an
imbalance, and start migrating the least recently used pages from the node
under most pressure to the node under least ...

M.