home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!sunic!corax.udac.uu.se!corax.udac.uu.se!ewerlid
- From: ewerlid@ida.docs.uu.se (Ove Ewerlid)
- Newsgroups: comp.os.linux
- Subject: Re: Linux Scheduling (Was Re: Die Die Die) (long)
- Date: 2 Jan 93 20:55:46
- Organization: University of Uppsala, Sweden
- Lines: 28
- Distribution: world
- Message-ID: <EWERLID.93Jan2205546@ida.docs.uu.se>
- References: <BzM129.Lp@brunel.ac.uk> <1992Dec21.155544.20713@mcs.gvsu.edu>
- NNTP-Posting-Host: ida.csd.uu.se
- In-reply-to: wissner@perlis.mcs.gvsu.edu's message of Mon, 21 Dec 1992 15:55:44 GMT
-
-
- [ This message seems to be dated 21 Dec 1992 but it appeared here today ?!?! ]
-
- wissner@perlis.mcs.gvsu.edu (Jim Wissner) writes:
- > environment) - things can get pretty nasty. What I have implemented
- > is a multi-level feedback queue, which currently using only two queues:
-
- Isn't the real problem to determine the type of the incomming process.
- E.g. should it go in the interactive (high pri) or batch (low pri) queue.
-
- Can't the batch compile problem be solved using 'nice make'?
- (Or 'nice -14 make' for a really low priority.)
- (Note that all processes forked by make inherits the priority given to make.)
-
- This problem is, IMHO, distinct from the problem of preventing the system
- from looking up when it is given large (and pathological) workloads.
- 'nice' exists so the user can hint the system about a low priority job
- when this is known.
-
- An incoming job that is 'niced' will have a lower priority than init
- or any typical interactive process.
- Thus, when the scheduler scans all process to find the process with the highest
- priority it will not immediately select incoming 'niced' processes.
- (It doesn't matter that init lives in process slot 1 and processes are scanned
- from the highest numbered slot.)
-
- Just some idle thoughts resulting in the conclusion that
- 'nice' is a nice command in a multitasking environment.
-