Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!hp4nl!ruuinf!ruunsa!cschreur
From: cschreur@ruunsa.fys.ruu.nl (Toine Schreurs)
Newsgroups: comp.sys.sgi
Subject: Re: Problem with nice
Summary: Swapping is your problem!
Message-ID: <1400@ruunsa.fys.ruu.nl>
Date: 8 Aug 90 07:05:29 GMT
References: <9008072224.AA21964@chaos.ocean.fsu.edu>
Organization: University of Utrecht, Dept. of Physics
Lines: 25

In <9008072224.AA21964@chaos.ocean.fsu.edu> steve@CHAOS.OCEAN.FSU.EDU 
(Steve Van Gorder) writes:

>I was under the impression from previous discussions in this news group
>and from reading the manuals that if I type  "npri -h 250 -p pid" as superuser
>then this process would be assigned a "non-degrading" priority of 250. 
>According to schedctl(2) man page this means that it is of lower priority than
>all other processes and shouldn't interfere with ANY interactive job.

>It doesn't seem to work that way to me at all.  In particular the window
>manager can become almost totally usless if there are even few jobs running
>in background ... and even if they have been "NPRIed" into oblivion.

We also have that problem, I think I know why. The processes that cause the
trouble, make use of process-swapping/paging (look at ps -el, that is memory
in 4096byte blocks). My first suggestion is that paging is an important
system-operation, such that it is performed at a higher priority. Another
suggestion is that, if you wait (reading) for about 15 seconds, the
window-server process gets paged out for a significant part. I actually
watched this process from a nearby terminal (ps -el).

Our solution: work with a system-manager or in agreement. Suspend batch-jobs
that use large amounts of memory when you need the machine interactively.
--
Rob Hooft, hooft@chem.ruu.nl using someone-elses news account.