Xref: utzoo comp.unix.wizards:23999 comp.unix.programmer:1012 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: daemon help Message-ID: <19034@rpp386.cactus.org> Date: 7 Feb 91 14:18:45 GMT References: <2304@inews.intel.com> <19032@rpp386.cactus.org> <1991Feb07.072540.28435@convex.com> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 19 X-Clever-Slogan: Recycle or Die. In article <1991Feb07.072540.28435@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I don't really suggest this. It's probably not worth it. Should your >whole system wait just so you can get a better snapshot of the proc >table? You should be able to slurp the entire proc table in one read from /dev/kmem atomically. (Except on certain platforms which actually do have pre-emptive scheduling ...) The transfer would be memory to memory. Even my slow, stupid, 68K box does about 4MB/s, so a 32KB proc table (which is plenty big on stupid PC's) would transfer in about 8ms. Certain fields (wait channel, for example) won't be accurate because of interrupt servicing, but the time fields should all be perfectly fine. I don't know how fast my 386 is, but I'm sure it is still much slower than a Convex C220 ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.