Re: [rfc] optimise unlock_page



On Wed, 16 May 2007, Hugh Dickins wrote:

On Wed, 16 May 2007, Nick Piggin wrote:
On Wed, May 16, 2007 at 06:54:15PM +0100, Hugh Dickins wrote:
On Sun, 13 May 2007, Nick Piggin wrote:

Well I think so, but not completely sure.

That's not quite enough to convince me!

I did ask Linus, and he was very sure it works.

Good, that's very encouraging.

Note that our default spinlocks _depend_ on a bog-standard store just
working as an unlock, so this wouldn't even be anything half-way new:

static inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
asm volatile("movb $1,%0" : "+m" (lock->slock) :: "memory");
}

There are some Opteron errata (and a really old P6 bug) wrt this, but they
are definitely CPU bugs, and we haven't really worked out what the Opteron
solution should be (the bug is apparently pretty close to impossible to
trigger in practice, so it's not been a high priority).

The other option of moving the bit into ->mapping hopefully avoids all
the issues, and would probably be a little faster again on the P4, at the
expense of being a more intrusive (but it doesn't look too bad, at first
glance)...

Hmm, I'm so happy with PG_swapcache in there, that I'm reluctant to
cede it to your PG_locked, though I can't deny your use should take
precedence. Perhaps we could enforce 8-byte alignment of struct
address_space and struct anon_vma to make both bits available
(along with the anon bit).

We probably could. It should be easy enough to mark "struct address_space"
to be 8-byte aligned.

But I think you may not be appreciating how intrusive PG_locked
will be. There are many references to page->mapping (often ->host)
throughout fs/ : when we keep anon/swap flags in page->mapping, we
know the filesystems will never see those bits set in their pages,
so no page_mapping-like conversion is needed; just a few places in
common code need to adapt.

You're right, it could be really painful. We'd have to rename the field,
and use some inline function to access it (which masks off the low bits).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/