A question on Unix/Ultrix CPU scheduling

[Stephen Carroll]

In article <2724 at bgsuvax.UUCP>, nijhawan at bgsuvax.UUCP (Sandeep Nijhawan) writes:
> 
> 
> 
> I 've been doing some work with the Ultrix (V2.0-1) cpu scheduling
> algorithms and have the following question(s) -
> 
> 	If the Super User were to increase the priority of a process by
> using /etc/renice to the maximum possible (-20) and then run a program
> with an infinite loop (completely cpu-bound), would any other user
> process on the system get the cpu at all until the priority of the super
> user's process went below PUSER ? Why?
> 

To begin, this sounds like a question that should have been posted to
comp.unix.wizards, not to general unix questions.

The priority scheduling scheme of unix is set up such that a super user process
running a nice of -20 cannot completely preempt other processes running at
normal nice of 0.  At each 1 second interval, the process priorities are 
computed such that the nice'd process' priority will eventually rise above
PUSER, thus allowing other processes the ability to run.

> 	I modified setpri() in kern_synch.c so that a process with a
> certain uid would always be given a priority of (PUSER - 1) irrespective
> of its p_cpu value. After I rebuilt the kernel and ran an infinte-loop
> process with that uid, I could still run other processes with other uids
> though they ran much less frequently. Any ideas about what's going on?
> 

This sounded impossible at first.  It seems that a process whose priority is
always PUSER-1 will always be selected off the runq ahead of processes whose
priority is PUSER or greater. (That is of course processes running nice of
0 or greater).  But, consider the following scenario:  If other processes
were running ahead of the special uid process, which were not cpu bound 
processes (and would probably be sleeping on some event and priority lower
than PUSER-1).  Your special uid process gets started, runs for 1 sec, and
then gets switched out.  Then if in the meantime, a process sleeping on an
event has that event occcur (terminal i/o, disk i/o, etc.), it's priority
would be set to something less than PUSER-1, and would run ahead of your
special uid process.  This could continue as long as the normal processes
were voluntarily switched out rather than time sliced out.  Once all normal
processes were time sliced out, their priorities would be something greater
than or equal to PUSER, and would therefore never get to run because of
the priority of your special uid process being PUSER-1.

Apologies to those who feel this is too technical for comp.unix.questions.
I would have mailed a response, but I felt that the first part of this
question would be of general interest to all.



	Stephen B. Carroll
	Unisys Corporation

	UUCP:   ...!{ihnp4 | hpda | sun }!sp7040!sbc