Re: [rfc][patch] unlock_page speedup

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 18 Dec 2008, Andrew Morton wrote:
>
> On Fri, 19 Dec 2008 08:29:09 +0100 Nick Piggin <npiggin@suse.de> wrote:
> 
> > Introduce a new page flag, PG_waiters
> 
> Leaving how many?  fs-cache wants to take two more.

Hmm. Do we ever use lock_page() on anything but page-cache pages and the 
buffer cache?

We _could_ decide to try to move the whole locking into the "mapping" 
field, and use a few more bits in the low bits of the pointer. Right now 
we just use one bit (PAGE_MAPPING_ANON), but if we just make the rule be 
that "struct address_space" has to be 8-byte aligned, then we'd have two 
more bits available there, and we could hide the lock bit and the 
contention bit there too.

This actually would have a _really_ nice effect, in that if we do this, 
then I suspect that we could eventually even make the bits in "flags" be 
non-atomic. The lock bit really is special. The other bits tend to be 
either pretty static over allocation, or things that should be set only 
when the page is locked.

I dunno. But it sounds like a reasonable thing to do, and it would free 
one bit from the page flags, rather than use yet another one. And because 
locking is special and because we already have to access that "mapping" 
pointer specially, I don't think the impact would be very invasive.

				Linus