> 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/