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

[Andrew Morton]

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