Re: [PATCH] GFP_THISNODE for the slab allocator

[Paul Jackson <pj@sgi.com>]

Nick wrote:
> So that's the part where you wanted to see if a zone has any free
> memory pages. What you are doing is not actually seeing if a zone
> has _any_ free memory pages, but testing whether a given allocation
> type is within its corresponding watermarks.

Ah - now your point makes sense.  Yes, I should not have been looking
for _any_ free memory, but rather for memory satisfying the watermark
and other conditions of the current request.


And the question of whether the cached 'base' and 'cur' pointers should
be invalidated everytime a request has differing watermarks ... well I
can think of several answers to that question ... all sucky.

However ... Andrew has prodded me into some more simplification, which
will toss this 'retry' pointer in the ash heap of history.  See my
upcoming reply to his latest post.

I trust you will not mind that this 'retry' pointer gets thrown out ;).

Nick wrote:
> What we could do then, is allocate pages in batches (we already do),
> but only check watermarks if we have to go to the buddly allocator
> (we don't currently do this, but really should anyway, considering
> that the watermark checks are based on pages in the buddy allocator
> rather than pages in buddy + pcp).

I'll have to leave this matter to you.  It's not something I understand
well enough to be useful.

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