tchrist@convex.COM (Tom Christiansen) (02/07/91)
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)
jfh@rpp386.cactus.org (John F Haugh II) (02/07/91)
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.