lkml.org 
[lkml]   [1999]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: possible spinlock optimizations
Date
From
Kurt Garloff writes:
> On Tue, Sep 28, 1999 at 08:28:35PM +0200, Ingo Molnar wrote:
> > > ??? I am fixing nothing. The old code is not buggy.
[...]
> > 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.
[...]
> 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?

What about a CONFIG_DEVEL_SKEW option which ensures that slow-path
ought-not-to-execute-often code is disproportionately penalised? For
example, it could leave out the interrupt enable mentioned above, it
could put a delay in the global kernel lock and do similar things to
constructs that developers ought to be discouraged from using. Then
coarse-grained comparative benchmarks may well be able to pick up
where code isn't written as tightly as it ought to be.

Or even a /proc/kludgeometer counter which slow/discouraged/deprecated
core code paths could increment to show up bad code/drivers/patches.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.075 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site