Re: [proc.txt] Fix /proc/pid/statm documentation

[Roger Luethi]

On Fri, 06 Aug 2004 05:11:18 -0700, William Lee Irwin III wrote:
> Some of the 2.4 semantics just don't make sense. I would not find it
> difficult to explain what I believe correct semantics to be in a written
> document.

IMO this is a must for such files (and be it only some comments above
the code implementing them). I'm afraid that statm is carrying too much
historical baggage, though -- you would add yet another interpretation
of those 7 fields.

Tools reading statm would have to be updated anyway, so I'd rather
think about what could be done with a new (or just different) file.

For sysfs we have guidelines (e.g. sysfs.txt: "Attributes should be ASCII
text files, preferably with only one value per file. It is noted that it
may not be efficient to contain only value per file, so it is socially
acceptable to express an array of values of the same type.").

I'm not aware of anything comparable for proc, so it's hard to say
what a good solution would look like. Files like /proc/pid/status
are human-readable and maintenance-friendly (the parser can recognize
unknown values and gets a free label along with it; obsolete fields can
be removed). The downside is the performance aspect you pointed out:
Reading that file for every process just to grep for one or two values
is slow, and some of the unused data items might be expensive for the
kernel to produce in the first place.

It seems that most new information of interest is being added to
/proc/pid/status and friends these days. Are there any plans to
accomodate tool authors who are interested in additional information
but are wary of the increasing costs of these files?

A light-weight interface for tools could work like this (ugly):

$ cat /proc/pid.provided
Name SleepAVG Pid Tgid PPid VmSize VmLck VmData [...]
$ cat /proc/10235/VmSize.VmData
3380 144

Or use netlink maybe? It sure would be nice to monitor all processes
with lower overhead, and to have tools that can deal with new data
items without an update.

Roger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/