David Wragg writes:
Benjamin LaHaise <[EMAIL PROTECTED]> writes:
On Mon, Dec 18, 2006 at 11:50:08PM +0000, David Wragg wrote:

This patch (against 2.6.19/2.6.19.1) adds the four context
switch values (voluntary context switches, involuntary
context switches, and the same values accumulated from
terminated child processes) to the end of /proc/*/stat,
similarly to min_flt, maj_flt and the time used values.

Hmmm, OK, do people have a use for these values?

Please put these into new files, as the stat files in /proc are
horribly overloaded and have always been somewhat problematic
when it comes to changing how things are reported due to internal
changes to the kernel.  Cheers,

No thanks. Yours truly, the maintainer of "ps", "top", "vmstat", etc.

The delay accounting value was added to the end of /proc/pid/stat back
in July without discussion, so I assumed this approach was still
considered satisfactory.

/proc/*/stat is the very best place in /proc for any per-process
data that will be commonly needed. Unlike /proc/*/status, few
people are tempted to screw with the formatting and/or spelling.
Unlike the /sys crap, it doesn't take 3 syscalls PER VALUE to
get at the data.

The things to ask are of course: will this really be used, and
does it really belong in /proc at all?

Putting just these four values into a new file would seem a little
odd, since they have a lot in common with the other getrusage values
that are already in /proc/pid/stat.  One possibility is to add
/proc/pid/rusage, mirroring the full struct rusage in text form, since
struct rusage is already part of the kernel ABI (though Linux doesn't
fill in half of the values).

Since we already have a struct defined and all...

sys_get_rusage(int pid)

Or perhaps it makes sense to reorganize all the values from
/proc/pid/stat and its siblings into a sysfs-like one-value-per-file
structure, though that might introduce atomicity and efficiency issues
(calculating some of the values involves iterating over the threads in
the process; with everything in one file, these loops are folded
together).

Yeah, big time. Things are quite bad in /proc, but /sys is a joke.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to