Re: [PATCH] GFP_THISNODE for the slab allocator

[Nick Piggin <nickpiggin@yahoo.com.au>]

Paul Jackson wrote:
> Nick wrote:
> 
>>Too complex? ;)
> 
> 
> I quite agree it looks more complex than we wanted.
> 
> 
> 
>>Why not just start with caching the first allowed
>>zone and see how far that gets you?
> 
> 
> I thought I had explained clearly why that doesn't work.
> 
> I'll try again.
> 
> I am presuming here that by 'first allowed zone' you are
> referring by yet another phrase to what Andrew has called
> 'most-recently-allocated-from zone', and what I described with:
> 
>   cur   -- the current zone we're getting memory from
> 
> If that presumption is wrong, then my reply following is bogus,
> and you'll have to explain what you meant.
> 
> I can't just cache this zone, because I at least have to also cache
> something else, such as the zonelist I found that zone within, so
> I know not to use that cached zone if I am later passed a different
> zonelist.
> 
> So I need to cache at least two zone pointers, the base zonelist and
> the first allowed zone.
> 
> Then I do need to do something to avoid using that cached zone
> long after some closer zone gets some free memory again.  Caching a
> revolving retry zone pointer is one way to do that.  Perhaps there
> are simpler ways ... I'm open to suggestions.

Oh no, I'm quite aware (and agree) that you'll _also_ need to cache
your zonelist. So I agree with you up to there.

The part of your suggestion that I think is too complex to worry about
initially, is worrying about full/low/high watermarks and skipping over
full zones in your cache.

The reason is that it will no longer be a identically functioning
cache, but would include heuristics where you fall back to checking
previously skipped zones at given intervals... I really hate having to
add a heuristic "magic" type of thing if we can avoid it.

So: just cache the *first* zone that the cpuset allows. If that is
full and we have to search subsequent zones, so be it. I hope it would
work reasonably well in the common case, though.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>