Re: What /proc should contain [was: /proc/driver/microcode]

From: Albert D. Cahalan (acahalan@cs.uml.edu)
Date: Thu Feb 24 2000 - 11:58:43 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/



This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:10 EST