Re: fast path for anonymous memory allocation

Nick Piggin
2004-11-19T02:44:25Z

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