Re: possible spinlock optimizations
Ton Hospel (thospel@mail.dma.be)
30 Sep 1999 00:08:33 GMT
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/