"Deep Background" applications
Daniel R. Levy
levy at ttrdc.UUCP
Sun Jun 26 13:41:24 AEST 1988
In article <11019 at cgl.ucsf.EDU>, seibel at cgl.ucsf.edu (George Seibel) writes:
#In article <29500025 at urbsdc> aglew at 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-----|
More information about the Comp.unix.questions
mailing list