Yeah, sorry, my posting was 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.
Taking your perspective: The CPU gets stolen from my CPU intensive task
immediately, whenever a signal or interrupt makes a blocking I/O bound
process runnable. [I may have misunderstood something in the Linux
scheduling policy, but I believe it's like that.]
So the amount of CPU I get, depends on the number of such events and
this should not be dependent on HZ.
> 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.
It doesn't matter. Assume you have set up the scheduling rate twice as high.
The web server will still process two requests A and B in the same amount of
time (plus scheduling overhead, of course).
AA.BB.
ABA.B.
The . indicates finished here. OK, the first case has the slight advantage
to have the A job answered one HZ tick earlier.
> 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.
This might make the kernel suitable for some special things, like RT apps
which drive devices in userspace (iopl) and therefore cannot block on waiting
for events. For normal usage, I think we don't need this.
> 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.
Processes performing system calls to do I/O are also taken away the CPU, if
O_NONBLOCK isn't used on Linux. That's what blocking is about.
> 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.
It wouldn't be a good idea to loose the CPU just because you want to know
your pid and perform the getpid() system call. I prefer the kernel
rescheduling on _some_ system calls. I believe that is what it does,
currently. (Sorry, I'm too lazy to check, at the moment.)
Maybe some of the scheduling gurus can tell, if I missed something.
-- Kurt Garloff <kurt@garloff.de> [Dortmund, FRG] Plasma physics, high perf. computing [Linux-ix86,-axp, DUX] PGP key on http://www.garloff.de/kurt/ [Linux SCSI driver: DC390]- 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/