>
> 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.
This would make a good discussion point, since it is a topic I am
highly interested in. Take a process whose nice value is 0. And
a process that has been niced to +10. What is the expectation there?
I'd _really_ like to have a nice value that says "don't run unless you
are twiddling your thumbs". Ie a nice 20 perhaps, that says I don't want
this to run unless there is _nothing_ else to schedule. But I'd also
like to be able to pick a nice value that means 'something'. IE on
the old LTSS system running on Crays out at Lawrence Livermore, we
used a fractional priority system. If you ran at 1.000, and I ran at
2.000, I simply got two times as much cpu as you did. (I got charged
twice as much, too). The nice thing was that I could figure out
what priority to use to kind of 'order' how things would finish.
Anybody interested in trying to make something like this work? IE
at present nice 1, nice 2, etc don't seem to make much difference,
and would be about as useful as just nice xxx to run at +10. I'm
always willing to tweak around with this, or to test ideas. But
the 'don't run unless nothing else is runnable' is a very useful
thing. IE it would perfect for the RC cracking project... among
other things...
>
> > > 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
>
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu
>
-
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/