Messages in this thread | | | Date | Fri, 15 Jan 1999 02:31:10 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: [uPATCH] SMP scheduling fix (?) |
| |
On Fri, 15 Jan 1999, Rik van Riel wrote:
> > (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/
| |