On Sun, 24 Aug 1997, Phil Schwan wrote:
> While I was working on an LCD driver and fixing procps top, Andrew Kroll and I
> hit upon the idea that adding a line to /proc/stat with the number of
> sleeping, running, disk sleeping, zombied, etc. processes would save a lot of
> processing time for programs that needed that information. Counting them from
> /proc more than doubled our driver's cpu usage, and calculating the 6 values
> in-kernel seems to be immensely faster than querying all of those directories
> in /proc.
>
> I went ahead and wrote the patch, but I noticed that it increases the cpu time
> of a cat /proc/stat by 30-35% and I wondered if it would be smarter to put it
> in it's own file. Only programs that need those counts would benefit from
> this extra line/file, and it might be on the whole smarter to just put it
> someplace where it can only be called as needed?
>
Would it not be simpler to implement a set of system calls to return
process information? No matter how much you optimize /proc its still a
big drain on resources. (example: Top takes 5% CPU on PPro200 with ~100
processes running. HP/UX "top" consumes less than 2% for ~400 procs on a
PA-7150 100Mhz).
I'm very much in favor of the VMS "$GETJPI"-like interface. It
accepts as an argument an array of field descriptors (one for every
requested process attribute) and a pid/procname/wildcard argument
that specifies the process to find.
Is this type of interface being worked on or would anyone mind
terribly if it was implemented? An even better question: would this
have a chance of being accepted into the kernel? Linus?
Regards,
Y.