Re: possible spinlock optimizations

Chuck Lever (cel@monkey.org)
Tue, 28 Sep 1999 15:45:06 -0400 (EDT)


On Tue, 28 Sep 1999, Ingo Molnar wrote:
> > The changes doesn't impact at all the fast path. It will only decrease the
> > irq latency during contection with the only cost of running _a_ cli before
> > trylock _only_ each time we exit from the slow path.
>
> it's not only a question of wether some patch impacts the preferred good
> case. 'good' is always relative to the bad case, and if you make the 'bad
> case' appear less bad then you've also effectively hurt the good case. We
> want the 'good case' stick out loud and clear.

here's my bias: i think manfred's suggestion is reasonable.

there really isn't any reason to cut off all interrupts (on dual CPU
hardware) while waiting for an IRQ-masked critical section, especially if
you can handle an interrupt during the time you were spinning rather than
the time you were supposed to be running in the critical section.

essentially you're saying that you want to be sure that the bad cases are
visible so we can fix them. there would still be tools to measure how
contended are specific spinlocks. i would prefer using such a tool since
it gives me empirical data, rather than waiting to experience slight
jerkiness in my GUI, for instance. in other words, why do we need to
prevent a subjective improvement to preserve a subjective indicator of
spinlock contention?

(more time at the pub might be an acceptible answer :)

besides, making the IRQ-masked spinlocks interruptible might mean that
we're more likely to interrupt a deadlock via SysRq, right?

- Chuck Lever

--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/

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