Re: Maximum frequency of re-scheduling (minimum time quantum ) que stio n

[Con Kolivas]

Andrew Morton writes:

> Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/