ppc32: Weird process scheduling behaviour with 2.6.24-rc
Michel Dänzer
michel at tungstengraphics.com
Mon Jan 28 20:14:33 EST 2008
On Mon, 2008-01-28 at 09:50 +0100, Peter Zijlstra wrote:
> On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
>
> > In summary, there are two separate problems with similar symptoms, which
> > had me confused at times:
> >
> > * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> > interactivity hickups with a niced CPU hog and top running. This
> > started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8.
>
> The revert at the bottom causes the wakeup granularity to shrink for +
> nice and to grow for - nice. That is, it becomes easier to preempt a +
> nice task, and harder to preempt a - nice task.
Yeah, that matches my observations. :)
> I think we originally had that; didn't comment it, forgot the reason
> changed it because the units didn't match. Another reason might have
> been the more difficult preemption of - nice tasks. That might - niced
> tasks to cause horrible latencies - Ingo, any recollection?
>
> Are you perhaps running with a very low HZ (HZ=100)? (If wakeup
> preemption fails, tick preemption will take over).
I haven't had it below 250 since that became an option, and I'm
currently at 1000 (and NO_HZ, but disabling that didn't seem to make a
difference).
> Also, could you try lowering:
> /proc/sys/kernel/sched_wakeup_granularity_ns
Will try.
> > * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
> > unusable with a niced CPU hog, with or without top running. I
> > don't know when this started, possibly when this option was
> > first introduced.
>
> Srivatsa found an issue that might explain the very bad behaviour under
> group scheduling. But I gather you're not at all interested in this
> feature?
That's right, but it's good to hear you have a lead there as well, and
if you can't find any interested testers, let me know and I'll try.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
More information about the Linuxppc-dev
mailing list