lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] sched: fix scheduling latencies for !PREEMPT kernels
William Lee Irwin III wrote:

>On Tue, 2004-09-14 at 21:46, William Lee Irwin III wrote:
>
>
>>>I've not heard a peep about anyone trying to fix this. It should be
>>>killed off along with the rest, of course, but like I said before, it's
>>>the messiest, dirtiest, and ugliest code that's left to go through,
>>>which is why it's been left for last. e.g. driver ->ioctl() methods.
>>>
>>>
>
>On Tue, Sep 14, 2004 at 10:00:44PM -0400, Lee Revell wrote:
>
>
>>Andrew tried to fix this a few times in 2.4 and it broke the FS in
>>subtle ways. Don't have an archive link but the message is
>><20040712163141.31ef1ad6.akpm@osdl.org>. I asked Hans directly about it
>>and he said "balancing makes it hard, the fix is reiser4", see
>><411925FA.2000303@namesys.com>.
>>
>>
>
>I have neither of these locally. I suspect someone needs to care enough
>about the code for anything to happen soon. I suppose there are things
>that probably weren't tried, e.g. auditing to make sure dependencies on
>external synchronization are taken care of, removing implicit sleeping
>with the BKL held, then punt a private recursive spinlock in reiser3's
>direction. Not sure what went on, or if I want to get involved in this
>particular case.
>
>
>-- wli
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Why bother? It is V3, it should be left undisturbed except for
bugfixes. Please, spend your efforts on reducing V4 latency and
measuring whether it fails to scale to multiple processors. That would
be very useful to me if someone helped with that. V4 has the
architecture for doing such things well, but there are always accidental
bottlenecks that testing can discover, and I am sure we will have a
handful of things preventing us from scaling well that are not hard to
fix. It would be nice to fix those......
The hard stuff for scalability, the locking of the tree, we did that.
We just haven't tested and evaluated and refined like we need to in V4.



Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2011 Jasper Spaans