Subject: Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory

From: Nishanth Aravamudan <[email-masked]>
Date: Tue, 4 Feb 2014 16:13:52 -0800

On 04.02.2014 [14:39:32 -0600], Christoph Lameter wrote:
> On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
> 
> > Yes, sorry for my lack of clarity. I meant Joonsoo's latest patch for
> > the $SUBJECT issue.
> 
> Hmmm... I am not sure that this is a general solution. The fallback to
> other nodes can not only occur because a node has no memory as his patch
> assumes.

Thanks, Christoph. I see your point.

Something in this area would be nice, though, as it does produce a
fairly significant bump in the slab usage on our test system.

> If the target node allocation fails (for whatever reason) then I would
> recommend for simplicities sake to change the target node to
> NUMA_NO_NODE and just take whatever is in the current cpu slab. A more
> complex solution would be to look through partial lists in increasing
> distance to find a partially used slab that is reasonable close to the
> current node. Slab has logic like that in fallback_alloc(). Slubs
> get_any_partial() function does something close to what you want.

I apologize for my own ignorance, but I'm having trouble following.
Anton's original patch did fallback to the current cpu slab, but I'm not
sure any NUMA_NO_NODE change is necessary there. At the point we're
deactivating the slab (in the current code, in __slab_alloc()), we have
successfully allocated from somewhere, it's just not on the node we
expected to be on.

So perhaps you are saying to make a change lower in the code? I'm not
sure where it makes sense to change the target node in that case. I'd
appreciate any guidance you can give.

Thanks,
Nish