Re: [uPATCH] SMP scheduling fix (?)

Robert M. Hyatt (hyatt@cis.uab.edu)
Fri, 15 Jan 1999 08:14:41 -0600 (CST)


On Fri, 15 Jan 1999, Neil Conway wrote:

> Robert M. Hyatt wrote:
> >
> > On Fri, 15 Jan 1999, Rik van Riel wrote:
> >
> > > On Thu, 14 Jan 1999, Robert M. Hyatt wrote:
> > >
> > > > 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?
> > >
> > > The expectation is that the +10 niced program gets half the
> > > CPU time from the 'normal' process.
> >
> > ok... then '20'??? IE it would seem that that might be 1/4th using
> > the same 'what number is next in this series?' :) That's not bad,
>
> Rather simpler than that... A nice value of 20 means you get about
> 1/20th as much as a process with a nice value of 0. 5% is too big for
> lots of things, and this is one of the reasons I like Rik et al.'s
> patches for sched_idle.
>
> Does anyone know why Linus doesn't like sched_idle things? (*Does* he
> dislike them??).
>
> Neil
>
> PS: Having bravely said the above without checking, I foolishly decided
> to check. It wasn't the case. Running two CPU-hogs, one non-niced and
> the other "nice +20", I got not the 95/5 split (actually 20/21 vs. 1/21
> was what I expected), but a roughly 91.5/8.5 split. This means that the
> niced process got about one eleventh of the CPU time.
>
> This doesn't square with what I read in the source code. "nice +20"
> should give the niced process (i386 values here) ONE time-slice in every
> round, while the non-niced should have 20 timeslices.
>
> Argh.
>

The path thru this code is torturous, because the priority can also
get bumped around for other reasons unrelated to the nice value. And
on SMP machines, we throw in more noise when we clammor for processor
affinity. :)

An ideal scheduler would give me the following options:

1. A way to 'scale' cpu activity so that I can say these two processes
should run at a ratio of 1:2. Or whatever.

2. A way to say "do not run this process unless there is _nothing_ left
to run (ie an idle-only task).

3. A way to say "run this process, period, except when it is blocked."
IE a process with more-or-less 'infinite' priority. I want to get this
done _now_ at times...

4. A way to say "give this process 1/4 of the cpu, at least, no matter
*what else* is running. Most research scientists want this because they
want to know *when* their process will finish. If they know it needs
2 hours of CPU, and they don't need the results for 8 hours, they could
say give this process 25% of all cycles (more if the cpu is idle of
course) to finish it in the right amount of time. IE we have a big Cray
here in Alabama, and our researchers here at UAB hardly use it because
they can't control how long it will take to run their jobs. So they go
off and buy SGIs or Alphas (which are much slower) because they provide
predictable run times. It would be interesting to see if this is doable
without one-process-per-machine type setups...

This latter is difficult because, of course, it conflicts with the others
to an extent. But since we are talking about what would be nice,
rather than what would be practical, thought I'd toss it out. And I hate
to talk about 'what would be nice' when we have a 'nice' command to make
that sentence read odd. :)

-
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/