Re: fast path for anonymous memory allocation

From: Nick Piggin <nickpiggin_at_yahoo.com.au>
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
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