Marko Kreen <marko@l-t.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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org