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

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