> > (Do you have some (simple or complex) testcase where we fail?)
>
> Yes, 2 niced +20 tasks taking up one CPU where 2 normal tasks
> (one using full CPU and X) taking up the other. The 'Right
> Thing' would be to let X switch to the other CPU and bother
> the niced tasks...
how much CPU time is X using, and how often does it reschedule? For
CPU-intensive tasks we definitely 'favor' higher priority processes and
distribute them amongst CPUs nicely. But if X in the above testcase isnt
CPU-intensive and/or does heavy reschedules then it's hard to tell.
i have tested this on a 4-CPU box, 4 reniced and 4 'normal' processes, and
CPUs nicely take 1 'normal' and 1 reniced process each.
> > ? it doesnt matter wether it's doubled or not, being on the
> > 'previous' CPU means it gets an (absolute) goodness boost.
>
> But if this boost puts it above a normal task it means that
> two normal tasks will bother eachother on one CPU and one
> (or two) niced tasks take up the other. Not Good :(
Note that even with your patch we are not correct. Yes we favor a +20
process against a +0 process because 20+0 > 0+0+1. But a +20 process
couldnt win against a +10 (still reniced) process because +20+0 <
+10+10+1. Also, p->counter can be considered randomly rotating, which
introduces unexpected non-scheduling as well.
> > why? SMP + caching issues are the same no matter what priority the
> > task has. Priority is mainly a way to control CPU-bound processes.
> > (interactive processes will have maximum priority anyway)
>
> While interactive processes may have maximum priority, I'd
> like it if the kernel would take a non-niced process from
> another CPU above a niced task from the current CPU when my
> editor is done. That way the non-niced tasks would tend to
> get out of eachother's way, only bothering the niced tasks
> and not eachother.
i suspect that in your case X is rescheduling heavily. If so then this is
a feature: we want to preserve the 'connection' between those two
processes. (look at the related() thing in sched.c)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/