lkml.org 
[lkml]   [2004]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Maximum frequency of re-scheduling (minimum time quantum ) que stio n
Date
Andrew Morton writes:

> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>> However well tested your scheduler might be, it needs several
>> orders of magnitude more testing ;) Maybe the best we can hope
>> for is compile time selectable alternatives.
>
> At this stage in the kernel lifecycle, for something as fiddly as the CPU
> scheduler we really should be 100% driven by problem reporting.
>
> If someone can identify a particular misbehaviour in the CPU scheduler then
> they should put their editor away and work to produce a solid testcase.
> Armed with that, we can then identify the source of the particular problem.
>
> It is at this point, and no earlier, that we can decide what an appropriate
> solution is. We then balance the risk of that solution against the severity
> of the problem which it solves and make a decision as to whether to proceed.
>
> Right now, the ratio of quality bug reporting to scheduler patching is
> bizarrely small.

Is "for fun" not reason enough?

I'm still keeping an eye out for firm "behavioural" bug reports on 2.6 and
would discuss or address them.

Seriously the only reason I went down the rewrite path was to address
complaints about the complexity of the current design. It was also an
opportunity to start implementing some requested features. I certainly have
never suggested it should even be considered for 2.6.

Con

-
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:04    [W:0.063 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site