Re: [PATCH] GFP_THISNODE for the slab allocator

[Paul Jackson <pj@sgi.com>]

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.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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>