nijhawan@bgsuvax.UUCP (Sandeep Nijhawan) (08/04/88)
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? 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? Any help would be much appreciated. Yes, I have Bach. Sandeep [I am sorry if this got posted twice]
david@linc.cis.upenn.edu (David Feldman) (08/04/88)
> From: nijhawan@bgsuvax.UUCP (Sandeep Nijhawan) > 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? > 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? > Any help would be much appreciated. Yes, I have Bach. The UNIX philosophy of process switching is that each process gets a maximum of one second (called the quanta) and then the process is switched out. Of the waiting processes that are ready to run, the one with the highest priority will be run next. So, a process that runs at a priority higher than any other process and has no need to wait (e.g. in a disk access or a page fault) will execute in every other process exec slot. My knowledge of this comes from v7m on a PDP-11, but I assume things have not changed too much. Also, process priorities drop over time if they are CPU hoggish, but this may not be the case if the pri is less than PUSER. I have never checked. _ /| Dave Feldman \'o.O' david@dsl.cis.upenn.edu =(___)= Ok, cough! U DSL - land of wonder and enchantment ACK! PHHT! Standard Disclaimer: I am not Bill. I have never been Bill. I don't ever intend to become Bill. I did not create the above representation of Bill. I don't have cash; send me the Bill.
sbc@sp7040.UUCP (Stephen Carroll) (08/05/88)
In article <2724@bgsuvax.UUCP>, nijhawan@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