Re: OT: nice'ing jobs
On Thu, Nov 30, 2000 at 06:10:20PM -0500, Brian Stults wrote:
> However, if one more CPU-intensive job were
> added by user1, all jobs would be slowed proportionately.
Have you tested that this actually happens? Empirical data is harder to
argue with than theory.
> My argument
> is that nice'ing the CPU-intensive jobs would cause the I/O-intensive
> job to run faster without slowing the CPU-jobs at all. The reason is
> that the I/O-intensive job doesn't use much CPU-time. So when it gets
> its turn on the CPU it doesn't use all of its allotted time.
> Generally speaking, is this correct in theory?
Nope. When a process is blocked waiting for I/O, it's automatically put to
sleep until it can run again. In theory, the I/O-intensive job won't receive
any CPU time at all until there's more data available for it to process (or,
on the output side, the hard drive catches up) and, when it gets a turn, it
will block and go back to sleep when it needs to wait for I/O again.
Niceness affects how frequently a task is allocated CPU time (and, sometimes,
the amount of CPU time it gets when it comes up). How the task handles its
time once it comes up is not affected by niceness.
> It seems especially
> considerate to nice the CPU-intensive jobs, since that user gets more
> aggregate CPU time anyway since they're running multiple big jobs.
Agreed, and that's what nice is there for. It is definitely a Good Thing to
use on big jobs, just not for the reason you think it is.
(Of course, I'm just a userland programmer and have never looked at the
kernel's scheduler, so my understanding of this may be slightly less than
perfect...)
--
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
Geek Code 3.1: GCS d? s+: a- C++ UL++$ P++>+++ L+++>++++ E- W--(++) N+ o+
!K w---$ O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv b+ DI++++ D G e* h+ r++ y+
Reply to: