Re: fast path for anonymous memory allocation

From: Benjamin Herrenschmidt <benh_at_kernel.crashing.org>
Date: 2004-11-19 18:05:20
On Fri, 2004-11-19 at 13:19 +1100, Nick Piggin wrote:
> Christoph Lameter wrote:
> > This patch conflicts with the page fault scalability patch but I could not
> > leave this stone unturned. No significant performance increases so
> > this is just for the record in case someone else gets the same wild idea.
> > 
> 
> I had a similar wild idea. Mine was to just make sure we have a spare
> per-CPU page ready before taking any locks.
> 
> Ahh, you're doing clear_user_highpage after the pte is already set up?
> 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).

Yah, doing clear_user_highpage() after setting the PTE is unfortunately
unacceptable. It show interesting bugs... As soon as the PTE is setup,
another thread on another CPU can hit the page, you'll then clear what
it's writing... 

Take for example 2 threads writing to different structures in the same
page of anonymous memory. The first one triggers the allocation, the
second writes right away, "sees" the new PTE, and writes just before the
first one does clear_user_highpage...

Ben.


-
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 Fri Nov 19 02:10:13 2004

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