On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little bogon with the PG_waiters bit that you already know
about but appart from that it should be ok.
I must say I absolutely _LOVE_ the bitops with explicit _lock/_unlock
semantics. That should allow us to remove a whole bunch of dodgy
barriers and smp_mb__before_whatever_magic_crap() things we have all
over the place by providing precisely the expected semantics for bit
locks.
There are quite a few people who've been trying to do bit locks and I've
always been very worried by how easy it is to get the barriers wrong (or
too much barriers in the fast path) with these.
There are a couple of things we might want to think about regarding the
actual API to bit locks... the API you propose is simple, but it might
not fit some of the most exotic usage requirements, which typically are
related to manipulating other bits along with the lock bit.
We might just ignore them though. In the case of the page lock, it's
only hitting the slow path, and I would expect other usage scenarii to
be similar.
Cheers,
Ben.
-
