root@spdyne.UUCP (01/27/89)
I have a question about the nice values of processes: A few years ago, I was working on a VAX 11/730 running BSD 4.2. When you would nice a process by say 2, you could tell the difference right away. It too considerably more or less time to complete. A make niced to -20 would zip along (and everyone else would stop). Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)), and only 3 Meg of ram. Microport UNIX with DOS-MERGE. (Sys V) As far as I can tell, the nice value does absolutly nothing! I have been running my makes +19 to allow other things to run and I can't even page up/down in VI in under a few seconds. It takes the same amount of time even if I nice -20, so what good does it do? One make kills the whole system. (or sending mail for that matter.. PS seems to bring things to a stop 80% of the time) Is it just the way that Sys V works or is it just that I don't have squat for ram? (Merge wants 2.6 Meg), Slow disks? (I know that the CPU waits on the transfer - right?) Also, Does anyone have a 'renice' for Sys V? I have one for BSD, but of course it is worthless under Sys V. -Chert Pellett root@spdyne
kai@uicsrd.csrd.uiuc.edu (01/29/89)
> Written by root@spdyne.UUCP > A few years ago, I was working on a VAX 11/730 running BSD 4.2. When > you would nice a process by say 2, you could tell the difference right away. > Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)), > and only 3 Meg of ram. Microport UNIX with DOS-MERGE. (Sys V) > As far as I can tell, the nice value does absolutly nothing! > I have been running my makes +19 to allow other things to run and > I can't even page up/down in VI in under a few seconds. > It takes the same amount of time even if I nice -20, so what good does it > do? From what I understand, some PC versions of UNIX are based on Sys V.2, which didn't page, it only swapped entire processes in or out. Since the nice value only affects cpu scheduling, chances are your compiles are taking up more memory than is left, and your edit is getting swapped out. Adding memory might help. If you OS is based on V.2, upgrading to a newer release might make some difference too. Patrick Wolfe pat@kai.com pat%kai.com@uxc.cso.uiuc.edu {uiucuxc,uunet,sequent,alliant}!kailand!pat pat@kai.com@uiucvmd.bitnet pat%kai.com@uiucuxc.arpa
bill@twwells.uucp (T. William Wells) (01/30/89)
In article <1800006@spdyne> root@spdyne.UUCP writes:
: I have a question about the nice values of processes:
:
: Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)),
: and only 3 Meg of ram. Microport UNIX with DOS-MERGE. (Sys V)
:
: As far as I can tell, the nice value does absolutly nothing!
: I have been running my makes +19 to allow other things to run and
: I can't even page up/down in VI in under a few seconds.
: It takes the same amount of time even if I nice -20, so what good does it
: do?
:
: Is it just the way that Sys V works or is it just that I don't have
: squat for ram? (Merge wants 2.6 Meg), Slow disks? (I know that the
: CPU waits on the transfer - right?)
(Sort of: the requesting process waits for the disk, but
anything that isn't waiting for the disk can run.)
I'm pretty sure that it is the seek time on the disks. Consider the
following scenario: two processes, each accessing the disk, with the
parts of the disk being accessed being fairly far apart. Each process
computes for a time less than half the seek time between their
sections of the disk. (The half comes because of read-ahead.)
When the first process waits on the disk, the second one goes; then
both are blocked waiting for the disk. Finally, the first process
gets its disk blocks and the disk seeks for the second processes'
blocks. The first process does its thing, but blocks waiting for the
disk, before the second set of blocks are available. Then, when
those blocks become available, the two processes switch roles. At no
time other than the beginning are the two processes contending for
the CPU; therefore, the nice value makes no difference.
There are two ways to fix this: either increase the amount of data
read after a seek, so that the processes block less frequently
waiting for a seek (and thus bringing them into contention) or using
the nice value to help control the disk queue. Note that doing the
latter can actually hurt performance if not done carefully. Note
also that both of these are kernel changes, we users can't fix them.
The amount of RAM might also make a difference, by increasing the
amount of paging being done. When I brought up my system, it used a
ridiculous amount of disk buffers; when I reduced it to something
reasonable, my system performance improved dramatically since those
ex disk buffers were now available for process space.
Here's an oddity for you: running a third, compute-bound, process can
actually improve your response time! What it does is to provide
contention with the lower priority process so that that process runs
less often. Because it runs less often, the disk seeks less
frequently, thus permitting your higher priority process to get its
data more quickly.
I did the experiment. Here is the script I used:
# initial nice is absolute 0, i.e., the max
# the input files are big (words is 791837)
# and /tmp is far from /usr (they are separated by my swap space)
exec >t.out 2>&1
time sed s/a/A/ </tmp/words >/dev/null &
time nice -20 awk 'BEGIN { for (i = 0; i < 10000; ++i) ; }' &
time nice -40 sed s/a/A/ </usr/words >/dev/null &
wait
wait
wait
Here are the timings:
clock 47 CPU 44 This for running one of the sed's by itself
clock 72 CPU 71 This for running the awk by itself
clock 162 CPU 52 This for both of the sed's running at the same time
clock 162 CPU 52
clock 57 CPU 44 This with everything: (first sed)
clock 168 CPU 74 (awk)
clock 152 CPU 44 (second sed)
As you can see, by running the awk in the background, the initial sed
runs almost as quickly as it would on an unloaded system.
Ah, the perils of process scheduling!
---
Bill
{ uunet!proxftl | novavax } !twwells!billdave@micropen (David F. Carlson) (01/30/89)
In article <1800006@spdyne>, root@spdyne.UUCP writes: > I have a question about the nice values of processes: > Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)), > and only 3 Meg of ram. Microport UNIX with DOS-MERGE. (Sys V) > > As far as I can tell, the nice value does absolutly nothing! > > Is it just the way that Sys V works or is it just that I don't have > squat for ram? (Merge wants 2.6 Meg), Slow disks? (I know that the > CPU waits on the transfer - right?) Nice affects the scheduler priority. It does not deal very well with the lower level system performance issues like "do I have more than 1 process able to run", etc. This is important with a machine with small RAM and a slow disk. Swapping or page faulting a running process blows it out for approx. that 40ms of drive seek time. No RAM with a large make (read at least 6 processes that must run to do your compile) can make for swap or DPVM thrash VERY easily. If your vi is paged out, it will not run until the page it needs make it through the diskIO queue, which can seem like forever. In summation, if a job is IO or memory (or both) bound, don't expect nice, (which is really affects CPU advantage) to do squat for you. > Also, Does anyone have a 'renice' for Sys V? I have one for BSD, but > of course it is worthless under Sys V. > -Chert Pellett > root@spdyne One of the UNIX source groups has renice in its archives. Look there. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
dave@onfcanim.UUCP (Dave Martindale) (02/10/89)
In article <1800006@spdyne> root@spdyne.UUCP writes: > > A few years ago, I was working on a VAX 11/730 running BSD 4.2. When >you would nice a process by say 2, you could tell the difference right away. >It too considerably more or less time to complete. A make niced to -20 >would zip along (and everyone else would stop). > > Now I'm running a Compaq 386/20, with (sorta slow drives (40ms)), >and only 3 Meg of ram. Microport UNIX with DOS-MERGE. (Sys V) > >As far as I can tell, the nice value does absolutly nothing! A 730 is *so* slow that you were probably waiting for the CPU most of the time, and the nice value determines how much CPU you got, so it determined responsiveness. A timesharing 780 was usually like this too - a bit faster CPU, but usually pretty fast disks and often several controllers, so you were still mostly waiting for the CPU. But on the Compaq, you've got a processor that is faster relative to the disk. So you're waiting for the disk most of the time, the CPU runs whatever it can whenever it can and still has lots of idle time, and nice just doesn't have any effect - every process gets as much CPU as it can use. What you really want is for niceness to control the priority of requests in the disk queue. But it doesn't.