Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re: Load control and intelligence in schedulers
Message-ID: <161@desint.UUCP>
Date: Fri, 19-Oct-84 16:56:41 EDT
Article-I.D.: desint.161
Posted: Fri Oct 19 16:56:41 1984
Date-Received: Sun, 21-Oct-84 14:27:25 EDT
References: <151@desint.UUCP> <4451@utzoo.UUCP>
Reply-To: ...!ihnp4!trwrb!desint!geoff (Geoff Kuenning)
Organization: his home computer, Thousand Oaks, CA
Lines: 25
Keywords: schedulers, interactive, terminal
Summary: Terminal *input*, not output, should give high priority

Henry Spencer writes:

>The problem with being smart about giving higher priority to processes
>that do terminal i/o is that all sorts of interesting programs start
>sprouting unnecessary terminal i/o.  I know of one large, hard-crunching
>compiler [name deleted to protect the guilty] which put out a NUL to
>the terminal each time it read a line of source, to keep its priority
>nice and high.  Argh.
>
>I'm not saying it can't be done well, just that care is needed.  Terminal
>input should be considered much more significant than output, for purposes
>of scheduling.

Programs that try to outsmart schedulers can be a serious problem.
But I wasn't talking about rewarding terminal output.  It is terminal
*input* that drives user's perceptions of response times, and thus
that is the only way to get a big priority kick.  Naturally, nobody
wants to 'babysit' a compute-bound program by giving it a CR every
second or so to keep it going (especially since a proper
implementation would ensure that only blocking reads gave the
priority boost).
-- 
	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff