Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd kernel auto-nicing, scheduling
Message-ID: <1685@utah-gr.UUCP>
Date: Wed, 19-Feb-86 11:44:57 EST
Article-I.D.: utah-gr.1685
Posted: Wed Feb 19 11:44:57 1986
Date-Received: Fri, 21-Feb-86 04:57:58 EST
References: <1014@brl-smoke.ARPA>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: University of Utah, Salt Lake City
Lines: 19


We have disabled this feature here in the past, since we have a tendency
to start an emacs in the morning and use it all day.  With subprocesses
throwing output into windows as fast as they can, it's really easy to
get more than 10 minutes of CPU in a day of work.  All of a sudden your
response slows to crawl:  "D**m it, my emacs just got auto-niced".  I
also experimented with code that looked at the ratio between system &
user time.  This prevented auto-nicing of emacs, I'm really not sure how
effective it was otherwise.  It certainly wouldn't have slowed down a
run away sendmail (which seems to be your problem).  The long-crunching
jobs would eventually get niced, which they should be anyway.  In fact,
we ask people to run jobs that are going to take a LOOONNGGG time to run
them at nice 19.  This can backfire if a process with a large RSS
(bigger than the physical memory) is running -- you get a very nasty
swapping/thrashing behaviour.  Some constant about how often a process
can be swapped is too small.

-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)