jbs@mit-eddie.UUCP (12/11/86)
The following applies to a 4.3BSD VAX: Recently, you may recall my having inquired about ways to have users be niced to different values without limiting them to a specific shell. I received a number of suggestions, but I didn't really like any of them, so I implemented my own "solution." My /bin/login now checks the file /etc/priorities for the group name or user name of the user logging in, and sets the user's priority to the priority found there. If both the user and group are found in the file, the priority listed for the user takes precedence. I'm willing to send out or post the changes if there is interest, and if someone convinces me that I won't be violating any license agreements or copyright laws by doing so. Anyway, now my question is, what are good nice values to use. What I want to achieve is giving significant preference to users in the higher groups when allocating CPU, without completely starving users in the lower groups. For example, if one user from each of two groups was logged in, running a job moderately heavy on the CPU (e.g. text formatter, C compiler, etc.), I'd like the "higher" user to get, say, twice as much CPU as the "lower" user. Similarly, if both were running a text editor on an otherwise moderately loaded system, I'd like the "higher" user to see response time better by maybe a factor of two. Right now, I have the values for each of three groups set at 0, 1, and 2, but I don't know if these values are sufficiently different to accomplish what I want, of if the magnitude of the priority difference is even significant. Jeff Siegal
mangler@cit-vax.Caltech.Edu (System Mangler) (12/17/86)
In article <4231@mit-eddie.MIT.EDU>, jbs@mit-eddie.MIT.EDU (Jeff Siegal) writes: > The following applies to a 4.3BSD VAX: > > Anyway, now my question is, what are good nice values to use. What I > want to achieve is giving significant preference to users in the > higher groups when allocating CPU, without completely starving users > in the lower groups. The effect of a given nice value is multiplied by the (1-minute) load average. When the load is low, there isn't much difference between the nice values; but when the load is 10, a one-point difference in nice value can make a factor of 2 difference in CPU share. When the load average is high, the CPU share of very "nice" processes can fall to zero. Usually this happens when nice value times load average is somewhere between 60 and 100. These processes stay in an "R" state for long periods, causing the load average to remain high and reinforcing the starved-out state for itself and any additional niced processes that cron may start up, and these jobs keep accumulating and never finishing. Thus the load average soars spectacularly. This last week, when the load reached the point of starving out rnews, the load on cit-vax went up in precisely this fashion (though response for nice 0 jobs was quite good). One time we observed an impatient user taking unfair advantage of this property. He didn't want to share the CPU with the nice 4 job that had been running for hours, so he started up 20 infinite-loop processes at nice 20. With the load average up at 22 or so, everything at nice 4 or worse was completely starved out. (This raised a lot of hell). Most nice user processes are that way because it was inflicted, not chosen, and generally those are all at nice 4. The 4.2/4.3 kernel automatically does this after 10 minutes of user time (most infinite loop processes are exempted either because they're all system time, or they run as root, e.g. sendmail). itcsh automatically nices its background processes by 4, and we have some compute-bound processes (like cifplot and spice) nice themselves by 4. When the load is very high, all those nice 4 processes form a "floor" with little or no CPU falling through to nicer processes. Thus, if you don't want to risk being starved out, don't use nice values larger than 4, and referring back to the first paragraph, you probably don't want to go that far. We run Pascal compilations at nice 3, essential daemons at nice 4, and news at nice 8 through 12, with afternoon load averages of typically 4 and occasionally 10. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
mark@ems.UUCP (Mark H. Colburn) (12/18/86)
It is possible to have a priority set for a specific user when they login by placing the 'pri=<priority_value>' into the gecos field in the /etc/passwd file. This works on System V.2, I do not know about Berkley. I am not sure if this is what you want or not. -- Mark H. Colburn UUCP: ihnp4!meccts!ems!mark EMS/McGraw-Hill ATT: (612) 829-8200 9855 West 78th Street Eden Prairie, MN 55344
jbs@mit-eddie.MIT.EDU (Jeff Siegal) (12/19/86)
In article <97@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes: >It is possible to have a priority set for a specific user when they login >by placing the 'pri=<priority_value>' into the gecos field in the /etc/passwd >file. This works on System V.2, I do not know about Berkley. I am not sure >if this is what you want or not. Just to confirm, this does _not_ work on Berkeley Unix, but anyone with a valid 4.3 license is welcome to my /etc/priorities code. Jeff