Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0

[Mark_H_Johnson]

>> > on low RT load (the common case) the scheduler behaves like the
>> > stock scheduler - the new logic only kicks in if a CPU runqueue has
>> > 2 or more RT tasks running at once.
>
>'the common case' == ordinary (non-RT) Linux boxes! When i implement
>scheduler features i'm always trying to make them as generic as
>possible, i.e. this feature too is structured to be as upstream
>mergeable as possible. For that purpose the change had to be
>low-overhead in the common, non-RT case.
I truly appreciate that. However...

>It is easy to hack the
>scheduler to fix some RT issue but break the generic scheduler - this
>solution is not meant to be such a hack.
I agree but I see the big delay of running the RT task to be a symptom
that the current non RT scheduler is somehow broken. I've reported the
non RT starvation condition several times. Yes, the second CPU is busy,
but I really do want to bump cpu_burn (which is non RT & nice) to run my
(non RT and not nice) stress script / commands instead.

--Mark H Johnson
  <mailto:Mark_H_Johnson@xxxxxxxxxxxx>

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