Re: possible spinlock optimizations

Malcolm Beattie (mbeattie@sable.ox.ac.uk)
Wed, 29 Sep 1999 12:30:26 +0100 (BST)


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/