Xref: utzoo comp.unix.wizards:23998 comp.unix.programmer:1009 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!convex!news From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: daemon help Message-ID: <1991Feb07.072540.28435@convex.com> Date: 7 Feb 91 07:25:40 GMT References: <2304@inews.intel.com> <19032@rpp386.cactus.org> Sender: news@convex.com (news access account) Reply-To: tchrist@convex.COM (Tom Christiansen) Organization: CONVEX Software Development, Richardson, TX Lines: 30 Nntp-Posting-Host: pixel.convex.com From the keyboard of bzs@world.std.com (Barry Shein): :That's a good point (see, you can tell the "wizards", they're the ones :willing to admit they may be wrong...:-) A true wizard is one whom only others refer to as such. This is not a perfect test, as a few ringers will slip in, but so it goes. The price of knowledge is learning how little of it you yourself harbor. :Looks like we need another option to ps...to increase clock res. :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. To truly get good accurate kernel stats, you need to lock the proc table, and I doubt you really want to pay to do that. I think on a Convex, at least, I could do without kernel changes it if wanted to badly enough: I'd map in kernel memory, then jack my priority up into the fixed scheduling range (like nice -64) such that I would run until I surrendered the CPU, then run through the table grabbing what I needed. 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? --tom -- "All things are possible, but not all expedient." (stolen out of context from Paul and reapplied to UNIX)