Messages in this thread | | | Date | Wed, 29 Sep 1999 13:36:38 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: possible spinlock optimizations |
| |
On Wed, 29 Sep 1999, Pavel Machek wrote:
> 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/
| |