Messages in this thread | | | Subject | Re: possible spinlock optimizations | Date | Wed, 29 Sep 1999 12:30:26 +0100 (BST) | From | Malcolm Beattie <> |
| |
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/
| |