dale@mddc.UUCP (Dale Anglin) (12/12/84)
[]
We have application programs that are normally utilized all day. They
are therefore reniced automatically. Currently, some users renice these
applications to a value of "one" to avoid this. This is not a good solution.
Removing the automatic renice feature (?) would not appear to be much better.
I would prefer that we had a mechanism to indicate that a particular process
should not be reniced. Is there such a beast? Please point me in the
right direction.
If the best we can do is no auto-renice, then would someone please help me
make this change.
If this has already been discussed, I appologize and please respond directly
via e-mail.
As seen before... advTHANKSance,
Dale Anglin
CARS Information Systems Corp (formerly a division of Management Decisions-mddc)
7209 Dixie Highway
Fairfield, Ohio 45014
(513)874-6464
...{ucbvax,decvax,ihnp4,mhuxi}!cbosgd!mddc!dale (uucp)sean@ukma.UUCP (Sean Casey) (12/14/84)
It seems to me a simple solution would be to remove re-niceing and write a daemon to renice cpu hogs. The main advantage of this would be that you would have complete control of what gets reniced. Sean
mwm@ea.UUCP (12/18/84)
/***** ea:net.unix-wizards / ukma!sean / 6:47 pm Dec 14, 1984 */ It seems to me a simple solution would be to remove re-niceing and write a daemon to renice cpu hogs. The main advantage of this would be that you would have complete control of what gets reniced. Sean /* ---------- */ Bingo. I've started one of these beasts already, having been inspired by the VMS "thumper" that does just that. I think the correct name for the thing is "external scheduler", and consider it as a replacement for the long-term half of the Unix scheduler (on the off chance that Unix actually has a long-term scheduler). Should you have source (lucky devils), this approach is silly. You would be better off rewriting the Unix scheduler. The daemon could be used to testbed different versions of the scheduler under load, though. <mike
rpw3@redwood.UUCP (Rob Warnock) (12/22/84)
+--------------- | Bingo. I've started one of these beasts already, having been inspired by | the VMS "thumper" that does just that. I think the correct name for the | thing is "external scheduler", and consider it as a replacement for the | long-term half of the Unix scheduler (on the off chance that Unix actually | has a long-term scheduler). | | Should you have source (lucky devils), this approach is silly. You would | be better off rewriting the Unix scheduler. The daemon could be used to | testbed different versions of the scheduler under load, though. | <mike +--------------- Why is it "silly" to have an external scheduler? The separation of algorithms into "policy" and "mechanism" components is often done (e.g. "Hydra/C.mmp"), and in fact many systems have done that for the scheduler. The kernel-resident part is sometimes called a micro-scheduler, and the part that runs as a (high-priority!) user process is a macro-scheduler. The macro-scheduler sets policy, and the micro-scheduler implements it via kernel mechanisms. Having the macro-scheduler in user mode makes it MUCH easier to interact with the environment (like operators, even). In certain situations, you may want to lock it in main memory (non-swapped), but all modern operating systems allow that, don't they? ;-} Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Ln, Foster City, CA 94404