* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > this fix is not complete - because the child runqueue is locked
> > here, not the parent's. I've fixed this properly in my tree and have
> > uploaded a new sched-modular+cfs.patch. (the effects of the original
> > bug are mostly harmless, the rbtree position gets corrected the
> > first time the parent reschedules. The fix might improve heavy
> > forker handling.)
>
> It looks like it did not reach your public dir yet.
oops, forgot to do the last step - should be fixed now.
> BTW, I've given it a try. It seems pretty usable. I have also tried
> the usual meaningless "glxgears" test with 12 of them at the same
> time, and they rotate very smoothly, there is absolutely no pause in
> any of them. But they don't all run at same speed, and top reports
> their CPU load varying from 3.4 to 10.8%, with what looks like more
> CPU is assigned to the first processes, and less CPU for the last
> ones. But this is just a rough observation on a stupid test, I would
> not call that one scientific in any way (and X has its share in the
> test too).
ok, i'll try that too - there should be nothing particularly special
about glxgears.
there's another tweak you could try:
echo 500000 > /proc/sys/kernel/sched_granularity_ns
note that this causes preemption to be done as fast as the scheduler can
do it. (in practice it will be mainly driven by CONFIG_HZ, so to get the
best results a CONFIG_HZ of 1000 is useful.)
plus there's an add-on to CFS at:
http://redhat.com/~mingo/cfs-scheduler/sched-fair-hog.patch
this makes the 'CPU usage history cutoff' configurable and sets it to a
default of 100 msecs. This means that CPU hogs (tasks which actively
kept other tasks from running) will be remembered, for up to 100 msecs
of their 'hogness'.
Setting this limit back to 0 gives the 'vanilla' CFS scheduler's
behavior:
echo 0 > /proc/sys/kernel/sched_max_hog_history_ns
(So when trying this you dont have to reboot with this patch
applied/unapplied, just set this value.)
> I'll perform other tests when I can rebuild with your fixed patch.
cool, thanks!
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
