> But, Ingo, are we going to add udelay(5000) into slow path to make
> sure some abstract guy has motivation? Should we add udelay(5000) into
> select() in order to make people use poll()?
>
> Certainly not.
no, we obviously do not want to slow it down. Nevertheless the most we are
optimizing for is the 'slight contention' case. In that case it's very
unlikely that the spinlock contention period will be hit by an interrupt.
And still we pay the price of 1) doing a sti and possibly missing the
just-released spinlock by 7 cycles 2) when we _got_ the spinlock we have
spend another 7 cycles on cli. So we've slowed down the 'light contention
case' (a tiny bit) for the sake of the high spinlock contention case?
(additionally to David's arguments)
what i'm saying: the patch makes only a difference in cases which are
truly considered 'to be fixed'.
> I think that our slow path should be optimized, too. No need to talk
> about abstract bugs. No matter how finegrained our locks are, under
> some workload they still will content, and that's why it is good to
> optimize it, too.
even in the generic case of a patch (not this one) improving all aspects
of the slow path (and only the slow path) i still believe that it's not a
good design decision to allow patches that go beyond the 'simple slow
path' implementation. Optimizing/making more complex the slow path impacts
the future development of fast path negatively. The slow path should stay
simple and obvious.
removing the 'udelay(1000)' from the slow path is an acceptable patch,
because it makes the slow path more obvious and less complex.
if you are getting high contention on a spinlock, and you think that this
contention is valid, use a semaphore and you'll get all those lots
spin-cycles potentially recovered by the scheduler. (The semaphore 'slow
path' is a recognized optimization goal.)
-- mingo
-
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/