Xref: utzoo comp.unix.wizards:24172 comp.unix.programmer:1119 Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: deamon help Message-ID: <10005@dog.ee.lbl.gov> Date: 18 Feb 91 10:39:37 GMT References: <594@edpmgt.UUCP> <2304@inews.intel.com> <19032@rpp386.cactus.org> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 40 X-Local-Date: Mon, 18 Feb 91 02:39:37 PST >From: jfh@rpp386.cactus.org (John F Haugh II) >>... One problem I envision with the PS approach is that the CPU >>resolution is to the full second, and there are many processes which >>lurk about in the background and don't use much more than a second >>in a days time. In article bzs@world.std.com (Barry Shein) writes: >Looks like we need another option to ps...to increase clock res. 4.3reno++ (4.3785?) already gives time to 10 ms resolution: % ps u USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND torek 9409 13.3 0.7 128 55 q1 R+ 2:28AM 0:00.27 ps u torek 9339 0.2 0.7 150 37 q1 Ss 1:10AM 0:01.85 -csh (csh) >Seriously, grokking around in the kernel proc structures tends to be >fraught with peril unless you're really pre-disposed to that sort of >thing. Actually, there is a more basic problem, at least under 4BSD. It is not difficult to write a program that uses 80 to 90 % of the total available CPU time yet shows 0% CPU usage. This is due to a phase interaction between the scheduler and the process accounting code. They both run off the same clock, and you can rig things so that your process is not running when the next clock interrupt fires. I will not give out the details here, since defeating the accounting code causes the scheduler to think that your process is being bullied and thus it gets higher priority than all the others, allowing it to continue in its evil ways. In other words, this goofs up the usual resource sharing, and someone could use it to hog all the cycles. (Fortunately, if someone *does*, and two people do it, the two processes wind up exposing each other's tricks. The clever bad guy will find a way around this as well [such a way does exist].) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov