Path: utzoo!attcan!uunet!lll-winken!ames!hc!lanl!cmcl2!adm!xadmx!vger!willcox@urbana.mcd.mot.com
From: vger!willcox@urbana.mcd.mot.com
Newsgroups: comp.unix.wizards
Subject: Re: Changing the nice() value of a r
Message-ID: <18199@adm.BRL.MIL>
Date: 25 Jan 89 16:14:05 GMT
Sender: news@adm.BRL.MIL
Lines: 41

>2) It looks like you are running the program from a shell script. The
>   "nice" command is not build in (in the bourne shell), which means you
>   are now invoking twice as many processes, which aren't doing much, but
>   the nice process sits waiting for the database program to finish. The
>   system may start thrashing more, resulting in more idle time because
>   the system is waiting for page faults. On a heavily loaded system like
>   yours the cpu-usage should be close to 100%, and the higher the better.
>   Lower values mean you system is thrashing.

Might I correct a couple of misconceptions here? 

 a) Using the nice command does NOT require any more processes.  "nice"
    does not run your command as a subprocess, but rather execs your
    command.  Leaving out many details, it does essentially:

	nice (nice_value);
	execvp (argv[0], argv);

 b) In any reasonable system, a process that's been sitting idle will
    get swapped or paged out, leaving the memory available for active
    processes.  Idle processes won't contribute to thrashing, and in
    particular won't increase the number of page faults significantly.
    (If you were constantly creating extra processes, that would
    increase overhead, but that didn't appear to be the situation here.)

 c) In general, I would agree that higher CPU usage is better.  However,
    that's only true if the CPU is spending the time doing USEFUL
    work.  If you can reduce overhead and thereby increase idle time,
    that's good.  In this case, they apparently are getting the same
    amount of work done, are getting better interactive response, and
    have more idle time.  How could you argue that this is bad?  I'd
    guess that by adjusting priorities the number of process switches
    has been reduced, eliminating that unnecessary overhead.

David A. Willcox
Motorola Urbana Design Center
1101 E. University Ave.
Urbana, IL 61801
217-384-8500
UUCP: ...!uiucuxc!mcdurb!willcox
ARPA:	willcox@xenurus.Gould.COM (temporary mail address)