seibel@cgl.ucsf.edu (George Seibel) (06/26/88)
In article <29500025@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes:
]
][buncha stuff about Gould RT unix]
]
]Finally, may I say that Real Time UNIX features are useful for
]more than Real Time applications? For example, fixed priority
]scheduling - there have been many times that I wanted to have
]a "deep background" application, that would run only when the
]system is otherwise idle. No matter how much you nice, your
]process will still take some cycles away when the system isn't
]idle.
Boy, would that be nice. We have a job mix that includes a healthy
fraction of multi-day cpu burners. We'd really like a way to make
those jobs butt out when someone wants to run a short (10 min-1 hr)
job. Does anyone know of an easy way to do something like this on
a bsd 4.[2-3] system?
George Seibel, UCSF
seibel@cgl.ucsf.edulevy@ttrdc.UUCP (Daniel R. Levy) (06/26/88)
In article <11019@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel) writes: #In article <29500025@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: #]Finally, may I say that Real Time UNIX features are useful for #]more than Real Time applications? For example, fixed priority #]scheduling - there have been many times that I wanted to have #]a "deep background" application, that would run only when the #]system is otherwise idle. No matter how much you nice, your #]process will still take some cycles away when the system isn't #]idle. #Boy, would that be nice. We have a job mix that includes a healthy #fraction of multi-day cpu burners. We'd really like a way to make #those jobs butt out when someone wants to run a short (10 min-1 hr) #job. Does anyone know of an easy way to do something like this on #a bsd 4.[2-3] system? Maybe a watch-dog program could be kludged up to use SIGSTOP to suspend the multi-day jobs when another job goes into background? (If the new job takes too long, or when it finishes, the stopped jobs would be restarted with SIGCONT.) (Religious flame time :-) Maybe UNIX system priorities don't have a wide "dynamic range" as it were, but it can be just as bad if things were too much the other way (e.g., VMS). One thing about VMS that bugs me, is that small (even single) steps in priority have a BIIIIIIG effect on how much CPU a process gets. A process with priority=3 will get about 10% as much CPU as a simultaneously running process with priority=4. And with several interactive users running at priority 4, a process at priority 5 gets most of the CPU to itself and is hell on the users' response time. That doesn't leave much room for flexibility in tuning process priorities, in my view. UNIX systems are "nicer" ('scuse thuh pun) in that respect. -- |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY | AT&T Data Systems Group | AND ARE NOT TO BE IMPUTED TO AT&T. | Skokie, Illinois | |-----Path: att!ttbcad!levy-----|
cjosta@taux01.UUCP (Jon Sweedler) (06/26/88)
In article <2772@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <11019@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel) writes: >#In article <29500025@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >#]For example, fixed priority >#]scheduling - there have been many times that I wanted to have >#]a "deep background" application, that would run only when the >#]system is otherwise idle. No matter how much you nice, your >#]process will still take some cycles away when the system isn't >#]idle. Not true (at least according to the "renice" man page...) >#We'd really like a way to make >#those jobs butt out when someone wants to run a short (10 min-1 hr) >#job. Does anyone know of an easy way to do something like this on >#a bsd 4.[2-3] system? Yes, just run a process with a priority of 20 (see below). > >Maybe a watch-dog program could be kludged up to use SIGSTOP to suspend >the multi-day jobs when another job goes into background? (If the new job >takes too long, or when it finishes, the stopped jobs would be restarted with >SIGCONT.) This is much more complicated than necessary. According to the "renice" man page, running a process with a priority of 20 (PRIO_MAX really) will accomplish this (I don't know why it doesn't say this in the "nice" man page as well...): RENICE(8) UNIX Programmer's Manual RENICE(8) NAME renice - alter priority of running processes . . . Useful priorities are: 20 (the affected processes will run only when nothing else in the system wants to) -- Jon Sweedler ===== National Semiconductor (Israel) UUCP: {ames!amdahl,hplabs,sun,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com Paper: 6 Maskit st., P.O.B. 3007, Herzlia B 46104, Israel
cjosta@taux01.UUCP (Jon Sweedler) (06/26/88)
In article <779@taux01.UUCP> cjosta@taux01.UUCP (Jon Sweedler) writes: >This is much more complicated than necessary. According to the "renice" >man page, running a process with a priority of 20 (PRIO_MAX really) will ^^^^^^^^ Oops. This should be PRIO_MIN. And also, under BSD 4.2, PRIO_MIN is set to 19. Under BSD 4.3 it is 20. -- Jon Sweedler ===== National Semiconductor (Israel) UUCP: {ames!amdahl,hplabs,sun,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com Paper: 6 Maskit st., P.O.B. 3007, Herzlia B 46104, Israel
cjosta@taux01.UUCP (Jon Sweedler) (06/26/88)
In article <780@taux01.UUCP> cjosta@taux01.UUCP (Jon Sweedler) writes: >In article <779@taux01.UUCP> cjosta@taux01.UUCP (Jon Sweedler) writes: >>man page, running a process with a priority of 20 (PRIO_MAX really) will > ^^^^^^^^ >Oops. This should be PRIO_MIN. And also, under BSD 4.2, PRIO_MIN is >set to 19. Under BSD 4.3 it is 20. Sorry for the multiple postings, but I think I have it right this time... This is kind of bizarre, but what can you expect from Unix? Under true BSD 4.3, PRIO_MAX is defined as 20 and PRIO_MIN is defined as -20. Regular users can "nice" their processes from 0 to 20. Under two BSD 4.2 workalikes (DYNIX and Ultrix) that we have here, PRIO_MAX is defined as -20 and PRIO_MIN is defined as 20 (i.e. backwards from BSD 4.3 and thus the reason for my confusion). Regular users can "nice" their processes from 0 to 19 (despite the fact that in the Ultrix man page for "nice" it says from 0 to 20). "Standards are wonderful, there are so many to chose from..." -- someone -- Jon Sweedler ===== National Semiconductor (Israel) UUCP: {ames!amdahl,hplabs,sun,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com Paper: 6 Maskit st., P.O.B. 3007, Herzlia B 46104, Israel
dan@maccs.McMaster.CA (Dan Trottier) (07/08/88)
In article <11019@cgl.ucsf.EDU> seibel@hegel.mmwb.ucsf.edu.UUCP (George Seibel) writes: >In article <29500025@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >] >][buncha stuff about Gould RT unix] >] >][More stuff deleted about needing differing levels of background execution >][priorities. > >Boy, would that be nice. We have a job mix that includes a healthy >fraction of multi-day cpu burners. We'd really like a way to make >those jobs butt out when someone wants to run a short (10 min-1 hr) >job. Does anyone know of an easy way to do something like this on >a bsd 4.[2-3] system? > Yes. Use the BSD command called nice(1) when starting up the job. The scenario is as follows: All jobs run at niceness 0 by default - This means they equally share the cpu with other level 0 jobs Jobs that run at niceness > 0 get less of the cpu - This means they will get less cpu cycles than jobs with lower niceness values Jobs that run with niceness < 0 get more of the cpu - This means they will get more cpu cycles than jobs with higher niceness values - Only ROOT can set niceness to less that zero So in order to run a job in the deep background and thus only execute when nothing else needs the cpu you should use a line like: nice 20 myjob & If you want another background job to capture more of the cpu then try: nice 10 anotherjob & Try several combinations of these nicenesses and see what the effects are. I found that a utility called "top" does a nice job of showing you the top X number of jobs running on the system and the resources they are using. Sorry about posting this but I think many people will be interested in this. dan -- A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan -- Official scrabble players dictionary -- | dan@mcmaster.BITNET
mangler@cit-vax.Caltech.Edu (Don Speck) (07/10/88)
A niceness of 20 is neither necessary nor sufficient by itself.
The low-level scheduler gives the CPU to the ready-to-run process
having the smallest value of p_pri. Except during system calls,
this is the same as p_usrpri. For a "Deep Background" process,
you want the largest legal value of p_usrpri, namely 127, even
in the absence of CPU ticks. If you merely don't want to compete
with processes at nice 0, then 100 is enough.
N.B. "ps" and "top" display PRI = p_pri - PZERO (PZERO is 25).
In 4.2 BSD, p_usrpri works out to (in a *very* roundabout fashion
via a time recurrence in p_cpu):
p_usrpri = PUSER + (nrscale*avenrun[0] + 9)*(p_nice - NZERO)/4
plus CPU ticks. PUSER is 50 and nrscale is 2. Notice that the effect
of niceness is multiplied by the load average. Solving, we get:
loadavg for p_usrpri of
niceness --127-- --100--
28 1.0
20 3.2 0.5
10 10.9 5.5
4 34 20.5
Although 4.2 BSD doesn't allow a niceness of 28, it's easy enough
to modify donice(). Convex's version allows niceness up to 64.
The fact that any positive niceness can become "deep background"
at a sufficient load average makes it risky to "nice" anything
that has timeouts or holds some scarce resource.
System V doesn't seem to have a "deep background".
Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck