Messages in this thread | | | Date | Tue, 28 Sep 1999 20:28:35 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: possible spinlock optimizations |
| |
On Tue, 28 Sep 1999, Andrea Arcangeli wrote:
> On Tue, 28 Sep 1999, Ingo Molnar wrote: > > >no Andrea, this again is just fixing the symptom. Yes, we could zero pages > > ??? I am fixing nothing. The old code is not buggy.
by 'fixing the symptom' i ment 'making the symptom to go away'. The symptom (the effects of spinlocks held for a long time) can indeed be considered an 'abstract bug'.
> 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.
let me give you an example. Someone optimizes away one (hypotetical) higher contention spinlock in the networking code, then measures the effects of the patch. There might also be some 'boring final changes' to be done, but this kernel hacker first wants to see the effects of the hack. Now it might turn out that under heavy networking load the speedup disappears in the noise. (because the high contention spinlock in fact still lets networking interrupts to arrive, bhs to execute) The guy, instead of sending the patch to linux-kernel, goes out and is having a beer with his friends.
now in the second case, the patch will show a 5% speedup (because the less contended spinlock is now not a barrier to device interrupts anymore), the guy is happy, finishes and sends the patch in and we have a tiny bit better kernel. (he also might thus have less social life and a tiny bit less happy gf - which again shows that things are relative ;)
hiding symptoms without fixing the real cause of the symptoms is bad. [This does not mean we should put artificial delay loops into the spinlock slow path :)]
[i admit that the above case is unlikely to happen in RL, mostly because Dave and Alexey already got rid of most pesky networking spinlocks :)]
-- 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/
| |