Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 | From | Mark_H_Johnson@raytheon ... | Date | Mon, 6 Dec 2004 09:59:47 -0600 |
| |
>> > 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@raytheon.com>
- 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/
| |