Messages in this thread | | | Subject | Re: possible spinlock optimizations | Date | 30 Sep 1999 00:08:33 GMT | From | (Ton Hospel) |
| |
In article <19990929125249.45449@atrey.karlin.mff.cuni.cz>, Pavel Machek <pavel@atrey.karlin.mff.cuni.cz> writes: > Hi! > >> > >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'. > > But, Ingo, are we going to add udelay(5000) into slow path to make > sure some abstract guy has motivation? Should we add udelay(5000) into > select() in order to make people use poll()? > > Certainly not. > > I think that our slow path should be optimized, too. No need to talk > about abstract bugs. No matter how finegrained our locks are, under > some workload they still will content, and that's why it is good to > optimize it, too. > Pavel >
In fact, isn't the slow path rare enough that it doesn't hurt to add statistics counters that are unconditionaly enabled ? Then you can in fact log warnings in the kernel log in case of high lock contention, which will be a lot more noticed than "hey, doesn't my computer feel a tad slow" ?
- 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/
| |