Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: What /proc should contain [was: /proc/driver/microcode] | Date | Thu, 24 Feb 2000 11:58:43 -0500 (EST) |
| |
Jamie Lokier writes: > Albert D. Cahalan wrote:
>> My fix would be to add the exact same binary files that Solaris has >> and to make all non-process information invisible. The filesystem >> code could also be used for /sys or /kern, with a mount option to >> show everything but the processes. > > Would a binary file in each /proc/PID directory containing just > the right information for /proc be ok?
No, more than one binary file. Have one for each kernel struct or other logical grouping, but with extra-large data types. Maybe it is best to be compatible with Solaris:
--w------- 1 acahalan software 0 Feb 24 11:49 ctl -r-------- 1 acahalan software 0 Feb 24 11:49 watch -r-------- 1 acahalan software 68 Feb 24 11:49 cred -r-------- 1 acahalan software 152 Feb 24 11:49 auxv -r-------- 1 acahalan software 912 Feb 24 11:49 lstatus -r-------- 1 acahalan software 1232 Feb 24 11:49 status -r-------- 1 acahalan software 1440 Feb 24 11:49 sigact -r-------- 1 acahalan software 1920 Feb 24 11:49 map -r-------- 1 acahalan software 1920 Feb 24 11:49 rmap -r-------- 1 acahalan software 2296 Feb 24 11:49 pagedata -r-------- 1 acahalan software 3040 Feb 24 11:49 xmap -r--r--r-- 1 acahalan software 120 Feb 24 11:49 lpsinfo -r--r--r-- 1 acahalan software 256 Feb 24 11:49 usage -r--r--r-- 1 acahalan software 336 Feb 24 11:49 psinfo -r--r--r-- 1 acahalan software 536 Feb 24 11:49 lusage -rw------- 1 acahalan software 2121728 Feb 24 11:49 as dr-x------ 2 acahalan software 544 Feb 24 11:49 object dr-x------ 2 acahalan software 1184 Feb 24 11:49 fd dr-x--x--x 5 acahalan software 736 Feb 24 11:49 . dr-xr-xr-x 3 acahalan software 48 Feb 24 11:49 lwp dr-xr-xr-x 433 root root 262336 Feb 24 11:50 .. lr-x------ 1 acahalan software 0 Feb 24 11:49 cwd -> lr-x------ 1 acahalan software 0 Feb 24 11:49 root ->
And in that "object" directory:
-r-xr-xr-x 1 root other 3187388 May 7 1999 a.out -r-xr-xr-x 1 bin bin 16936 Aug 24 1999 ufs.32.22.45576 -r-xr-xr-x 1 bin bin 166196 Aug 24 1999 ufs.32.22.5782 -r-xr-xr-x 1 bin bin 19304 Jul 15 1997 ufs.32.22.5806 -r-xr-xr-x 1 bin bin 53656 Jul 16 1997 ufs.32.22.5818 -r-xr-xr-x 1 bin bin 721924 Aug 24 1999 ufs.32.22.6146 -r-xr-xr-x 1 bin bin 1014088 Oct 18 19:51 ufs.32.22.6148 -r-xr-xr-x 1 bin bin 4280 Aug 24 1999 ufs.32.22.6153
And in lwp/1, my only thread:
-r-------- 1 acahalan software 0 Feb 24 11:49 gwindows --w------- 1 acahalan software 0 Feb 24 11:49 lwpctl -r--r--r-- 1 acahalan software 104 Feb 24 11:49 lwpsinfo -r-------- 1 acahalan software 896 Feb 24 11:49 lwpstatus -r--r--r-- 1 acahalan software 256 Feb 24 11:49 lwpusage -r-------- 1 acahalan software 248 Feb 24 11:49 xregs
>> I'd love to have the binary structures for C. In spite of being >> 100% C, "top" can use 50% of my CPU time. Real code is C anyway. > > I minor tweak to "top" and procfs would fix that 50% CPU time > in the usual case. All you need is for readdir("/proc") to > return the processes in approximate reverse order of CPU usage, > and to have another file which reports idle time. Then "top" > can stop reading once it's reached a total of 100% CPU usage.
No, this isn't right. First of all, top can sort by %mem instead.
More importantly, /proc must be modified to group threads together. This is needed for a fast thread-aware ps. By default, ps should not have to sort processes. It should run fast.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |