> On Fri, Jan 08, 1999 at 09:14:14AM -0500, Richard B. Johnson wrote:
> > On Thu, 7 Jan 1999, Pavel Machek wrote:
> >
> > > You should _not_ need to increase HZ. But there've always been obscure
> > > "feature" in scheduler, and increased HZ work around it.
> > >
> > > Pavel
> >
> > There seems to be a general misinformation about what the HZ value is.
> > I will "simplicate and add lightness".
> >
> > If your code does:
> > while (1)
> > ;
> >
> > The CPU gets taken away from you HZ times per second so that other
> > tasks can use the CPU cycles you are wasting. Under these conditions
> > it seems like a good idea to make the HZ value as high as possible.
> >
> > However, if your code is doing:
> >
> > UncompressFonts(...........);
> > ReadAudioFromDsp(...........);
> > ConvolveImageData(..........);
> >
> > you don't want the CPU taken away until you are done.
> >
> > For most interactive applications, it has been experimentally determined
> > that 100 Hz is (about) right because human beings can't detect flicker
> > above 80 Hz. In other words, getting the CPU stolen 100 times per second
> > doesn't produce visual effects. The higher the HZ value, the more
> > often the CPU gets stolen from the interactive user. There are trade-
> > offs as with most everything.
> >
> > More is not better. More is just different.
>
> I think you didn't describe the tradeoff correctly. The amount of time a
> process gets are independent of HZ. HZ just defines its granularity.
>
> Let me describe this with a picture, where we have two runnable processes A
> and B: . . . . . . . .
> HZ = 100: AAAAAAAABBBBBBBBAAAAAAAABBBBBBBB
> HZ = 400: AABBAABBAABBAABBAABBAABBAABBAABB
>
> Both processes have the same priority and get the same amount of CPU. This
> is independent of the HZ value.
>
[SNIPPED rest because this would be too long]
The fatal flaw in the logic is that both (or all) tasks are CPU bound.
If I have something to do that takes only 1/100th of a second to do
before the machine is I/O bound (waiting for a keyboad or mouse-click),
I want to do it NOW, not after N-others processes steal my CPU. This
is the advantage of a long time-slice. The disadvantage, as you mentioned,
is that a computable process has to wait until I'm done. However, events
that use signals or interrupts happen NOW (minus switch overhead).
So again, the HZ value is the rate at which the CPU will get stolen
from YOU. This makes a trade-off necessary to consider rather than
"more slices/second is better". There is a lot to consider.
If I'm running a Web-Server, it just might be more advantageous to
increase the schedule-rate if, and only if, I can count on handling
a single server-event per time-slice. With fast CPUs, this might be
a good idea, but maybe not.
I am all for a tunable value, BTW. Even though there will be some
increased overhead in doing it. What one cannot get trapped into
is guessing that a higher value would be better because of some
"logical" reason. Logic fails because there are just too many variables.
That said, VMS (and I wish there was a Unix VMS) context-switches
on any/all system calls. If you need to open a file, you lose the
CPU and it gets given to somebody else, while the kernel is waiting
for disk I/O. This makes certain that all tasks that are computable
get a chance at the CPU. You don't have a single task hogging the
system.
The idea of switching and rescheduling in Linux upon every
system call (basically trivial, just schedule() before the request) just
might be worth a hack. This is what "they" did in the days of slow CPUs
and 100s of interactive users.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
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/