ardis@wanginst.EDU (Mark A. Ardis) (06/25/87)
Problem: After running Gnuemacs for awhile, my process gets "nice"ed. Response is pretty bad once this happens. The threshold seems to be around 12 minutes of CPU. We are running Ultrix 1.2 on a VAX 785. Questions: 1. Is there a magic threshold, after which a process automatically gets "nice"ed? 2. Is there a way to prevent this behavior for "special" processes? (I.e., can Ultrix be told not to "nice" certain programs?) 3. Are there any alternatives to killing and restarting the process? Thanks for any help you can give us. -- Mark A. Ardis ardis%wanginst@CSNet-Relay (CSNet) Wang Institute of Graduate Studies ...!decvax!wanginst!ardis (UUCP) 72 Tyng Road, Tyngsboro, MA 01879-2099 (617) 649-9731
nate@cpocd2.UUCP (Nate Hess) (06/26/87)
In article <1257@wanginst.EDU> ardis@wanginst.EDU (Mark A. Ardis) writes: > >Problem: > >After running Gnuemacs for awhile, my process gets "nice"ed. Response >is pretty bad once this happens. The threshold seems to be around 12 >minutes of CPU. We are running Ultrix 1.2 on a VAX 785. > >Questions: > >1. Is there a magic threshold, after which a process automatically > gets "nice"ed? > Auto-nicing can occur anytime after a process has racked up 10 minutes of CPU time. >2. Is there a way to prevent this behavior for "special" processes? > (I.e., can Ultrix be told not to "nice" certain programs?) > GNU Emacs can be compiled so as to run with a negative nice (-1, say). Look at the bottom of "config.h". This only works if the Emacs executable is setuid root. >3. Are there any alternatives to killing and restarting the process? One way of "cheating" the autonicing is to manually nice the emacs to +1 before it acquires 10 minutes of CPU time. Ultrix will see that the process has a nice factor, and not autonice it to +4 like it usually would. Hope this helps, --Nate -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!cpocd2!nate <domainish> : nate@cpocd2.intel.com ATT : (602) 961-2037
Karl.Kleinpaste@cbstr1.att.com (06/26/87)
Posting-Front-End: GNU Emacs 18.47.3 of Sat Jun 20 1987 on cbstr1 (usg-unix-v) Try nice'ing it 1 additional point when it starts up. The performance loss of one point is not noticeable by an ordinary user, and the fact that it has been nice'd at all will keep the kernel from renice'ing it later (by 4[?] points instead of 1). Karl
ram%shukra@Sun.COM (Renu Raman, Sun {Graphics Sub-Division}) (06/26/87)
In article <757@cpocd2.UUCP> nate@cpocd2.UUCP (Nate Hess) writes: >In article <1257@wanginst.EDU> ardis@wanginst.EDU (Mark A. Ardis) writes: >> >>Problem: >> >>After running Gnuemacs for awhile, my process gets "nice"ed. Response >>is pretty bad once this happens. The threshold seems to be around 12 >>minutes of CPU. We are running Ultrix 1.2 on a VAX 785. >> >>Questions: >> >>1. Is there a magic threshold, after which a process automatically >> gets "nice"ed? >> > >Auto-nicing can occur anytime after a process has racked up 10 minutes >of CPU time. > > >...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!cpocd2!nate ><domainish> : nate@cpocd2.intel.com ATT : (602) 961-2037 In BSD it occurs at the end of the 10th minute i.e. with start of minute 11 you get niced to +4. urogue players know this very will. --------------------- Renu Raman Sun Microsystems M/S 5-40, 2500 Garcia Avenue, Mt. View, CA 94043
mangler@cit-vax.Caltech.Edu (System Mangler) (07/06/87)
In article <757@cpocd2.UUCP>, nate@cpocd2.UUCP (Nate Hess) writes: > One way of "cheating" the autonicing is to manually nice the emacs to > +1 before it acquires 10 minutes of CPU time. Ultrix will see that the > process has a nice factor, and not autonice it to +4 like it usually > would. One night an NP-complete optimization problem was running at nice 4, and another, very impatient student wanted to get as much CPU as he could for *his* 3-hour job. He applied the above trick of nicing his job to 1, and then he started up twenty infinite-loop jobs at nice 20. The load average at this point shot up to 24. The BSD scheduler sees this, and cuts out niced processes much more sharply than usual, with the result that the nice 4 job and the nice 20 jobs got no CPU time. Served his purpose real well... Knowing how strident this student could be, I let him have his way for a while. Meanwhile, though, "nice 4" jobs piled up, because none of them could get runtime, and the load average kept increasing; a vivid demonstration of the built-in instability of the BSD scheduler. Eventually I had to kill all the infinite-loop processes. (I caught so much hell for this, that even two years later I still refuse to kill infinite loops without the owner's consent). The kernel auto-nicing is a kludge. It only checks cumulative user-mode cpu time. Things like "make" are untouched, as are "loop on EOF" jobs, the most common type of infinite loop around here. The infamous sendmail "fork and write until disk full" runaway is doubly exempt because it runs as root. How useful... Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
jbn@glacier.STANFORD.EDU (John B. Nagle) (07/07/87)
Whatever happened to the Maryland scheduler, which replaced the simple-minded UNIX scheduling system with reasonable algorithms? (Bear in mind that Richie and Thompson designed the process-table scheduler for a rather small machine, and that it scales up badly.) Scheduling was figured out in the 1960s (F.J. Corbato, Project MAC, MIT), by the way, and good algorithms are in the literature. One can do better than "auto-nicing". Much better. John Nagle
pdg@ihdev.UUCP (07/08/87)
In article <17118@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > Whatever happened to the Maryland scheduler, which replaced the >simple-minded UNIX scheduling system with reasonable algorithms? For another nicely implemented scheduler, see the AT&T BLTJ V63#8/2 (Oct 84) article by G.J. Henry on the Fair Share Scheduler. This distributes processing resources into assignable groups. Anyway, it's a good idea that we use on *very* large processors hereabouts. It does seem to have a few problems with more I/O bound stuff, though (GNUmacs runs so fast that zippy and the psychoanalyst talk megabytes/second!! :-) All in all, a large improvement. -- Paul Guthrie "Another day, another Jaguar" ihnp4!ihdev!pdg -- Pat Sajak
chris@mimsy.UUCP (Chris Torek) (07/10/87)
In article <17118@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes: >Whatever happened to the Maryland scheduler, which replaced the >simple-minded UNIX scheduling system with reasonable algorithms? It is still around. No one is working on it now, though, since Jeff got his thesis done. And I want a fair-share scheduler anyway. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris