[lkml]   [1999]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: possible spinlock optimizations
On Tue, Sep 28, 1999 at 08:28:35PM +0200, Ingo Molnar wrote:
> > ??? 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.

No, no, no.

If you optimize something, say a file-system by having the indirect blocks
next to the data blocks, you want to make sure, that
(a) this happens as often as possible
(b) this fast path is executed as fast as possible
And you want to add
(c) don't optimize the slow path in order to provide motivation for people
to fix the FS further to avoid it completely

You are right, if the slow path could be avoided completely by proper design.
In the FS, like in the spinlock case, it can't!

There are 8-way (and more) machines out there and you will have a hard time
to avoid spinlock contention completely, if you are I/O bound. So why not
decrease the bad effects of spinlock contention?

Kurt Garloff <> Wuppertal, FRG
PGP2 key: See mail header, key servers Linux kernel development
SuSE GmbH, Nürnberg, FRG SCSI drivers: tmscsim(DC390), DC395
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:54    [W:0.089 / U:12.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site