Re: fast path for anonymous memory allocation

From: Nick Piggin <>
Date: 2004-11-19 13:44:25
Christoph Lameter wrote:
> On Fri, 19 Nov 2004, Nick Piggin wrote:
>>Ahh, you're doing clear_user_highpage after the pte is already set up?
> The huge page code also has that optimization. Clearing of pages
> may take some time which is one reason the kernel drops the page table
> lock for anonymous page allocation and then reacquires it. The patch does
> not relinquish the lock on the fast path thus the move outside of the
> lock.

But you're doing it after you've set up a pte for that page you are
clearing... I think? What's to stop another thread trying to read or
write to it concurrently?

>>Won't that be racy? I guess that would be an advantage of my approach,
>>the clear_user_highpage can be done first (although that is more likely
>>to be wasteful of cache).
> If you do the clearing with the page table lock held then performance will
> suffer.

Yeah very much, but if you allocate and clear a "just in case" page
_before_ taking any locks for the fault then you'd be able to go
straight through do_anonymous_page.

But yeah that has other issues like having a spare page per CPU (maybe
not so great a loss), and having anonymous faults much more likely to
get pages which are cache cold.

Anyway, glad to see your patches didn't improve things: now we don't
have to think about making *more* tradeoffs :)
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Thu Nov 18 21:57:25 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:32 EST