arcege@golem.usmsas.maine.edu (Michael P. Reilly) (02/07/91)
Some systems allow a program to access kernal memory (through kmem and possibly swap) for process information. The C routine would be nlist(3), on SunOS, System V, and Ultrix at least. This returns the addresses (in memory) of variables in the executable. Then you can lseek into /dev/kmem to find the process table entry and look for the information there (you may have to lseek into swap as well in the process is swapped out of memory. The command nm(1), also on SunOS, System V and Ultrix, displays the symbol table of the executable to help find which variable names to search for. The system may have /dev/kmem and /dev/swap permissions set for no other access, but since this is a daemon, root ownership would allow access. I would suggest comparing values in the process table (for example, cpu-time, priority, nice-value, etc.) to determine what the process is doing relative to others and your desired values; also check the timing values of the process. I hope this helps! --Michael P. Reilly +=======================================+=====================================+ |Michael Reilly | Inter: arcege@cs.usmsas.maine.edu | |Unix Systems Admin/Analyst | BITNet: arcege@portland.bitnet | |Computer Science Dept. | ip60401@portland.bitnet | |University of Southern Maine | UUCP: (links temporarily down) | |96 Falmouth Street, Portland, ME 04103 | BellNet: (207) 780-4515 | +---------------------------------------+-------------------------------------+
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.