Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC840302); site hslrswi.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!cernvax!hslrswi!robert From: robert@hslrswi.UUCP (Robert Ward) Newsgroups: net.sources.bugs Subject: Re: SPS - a useful replacement for ps(1) (but....) Message-ID: <121@hslrswi.UUCP> Date: Wed, 3-Jul-85 15:43:58 EDT Article-I.D.: hslrswi.121 Posted: Wed Jul 3 15:43:58 1985 Date-Received: Sat, 6-Jul-85 10:21:15 EDT Organization: Hasler AG, Bern, Switzerland Lines: 28 Sean Casey (sean@ukma.UUCP) points out that sps runs at nice -20 and hence runs fast at the expense of other users. He even goes on to point out that typing "sps adefgvwr >/dev/null &" can have pretty dire consequences for everyone else. Well, of course, he is absolutely right. Sps does renice itself not just to go faster but also in an attempt to look at separate kernel data structures before they are changed too much or become too inconsistent with one another. In practise, however, it doesn't seem to affect the response time of sps too much whether it runs at nice -20 or nice 0. One solution, suggested by Jeffrey Mogul, is to renice sps only for root. This also means that sps need not be a setuid program. Here is the diff for main.c - 26,28c26,29 < /* Renice as fast as possible for root (Suggested by Gregorio!mogul) */ < if ( !getuid() ) < (void)nice( -40 ) ; --- > # ifndef TRACE > (void)nice( -40 ) ; > (void)setuid( getuid() ) ; > # endif Personally, I don't think it matters much either way. (Robert Ward, Hasler AG, Belpstrasse 23, CH-3000 Bern 14, Switzerland).