Re: Spinlocks, yet again: analysis and proposed patches

Marko Kreen <marko(at)l-t(dot)ee> writes:

> On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
> > The second reason that the futex patch is helping is that when
> > a spinlock delay does occur, it allows the delaying process to be
> > awoken almost immediately, rather than delaying 10 msec or more
> > as the existing code does. However, given that we are only expecting
> > the spinlock to be held for a couple dozen instructions, using the
> > kernel futex mechanism is huge overkill --- the in-kernel overhead
> > to manage the futex state is almost certainly several orders of
> > magnitude more than the delay we actually want.
>
> Why do you think so? AFAIK on uncontented case there will be no
> kernel access, only atomic inc/dec. On contented case you'll
> want task switch anyway, so the futex managing should not
> matter. Also this mechanism is specifically optimized for
> inter-process locking, I don't think you can get more efficient
> mechanism from side-effects from generic syscalls.
>
> If you don't want Linux-specific locking in core code, then
> it's another matter...

How does the futex using code compare with the new patches on this new
benchmark test?

--
greg