Re: /proc/cpuinfo verbiage differ unnecessarily between ports...

Mark Hahn (hahn@coffee.psychology.mcmaster.ca)
Fri, 3 Sep 1999 16:40:20 +0000 ( )


> Glen> As the author of some SNMP code, I'd like to see the *whole* of
> Glen> /proc adopt a consistent, simple to parse, simple to read,
> Glen> simple to write structure.

that would be nice. linux-perf contained some discussions about how
to improve the parsability, especially through changes. the main idea
was to include some kind of metadata, self-description. another cute
trick was to use seek to skip the metadata, or perhaps even select fields.

when this topic comes up, there's always discussion of formatting,
how some people would prefer a binary interface (as in sysctl or SNMP)
and how it's such a bummer that different versions (and arch's) have
incompatible shifts in format.

> than having your user space tool parse /proc. Having the kernel
> generate ascii strings, then copying these to user space just to have
> the user space application reparse them in the end is pretty expensive
> when all you really want is to read an integer value or two.

it's not, actually. this kind of interface will always require a syscall,
and in the face of that, formatting and parsing is trivial.

> Once you start cranking up the sample frequency the monitoring can
> actually start affecting the system load.

I think this more reflects the amount of work the kernel has to do to
collect some of the numbers. there a couple solutions to this:
selecting only the numbers you want or improving the kernel code.
I can also imagine a kernel system that's specifically designed to
extract periodic measurements, and buffer them. then a user-level app
could read whole batches of measurements, with far fewer syscalls.
(not unlike the klog interface, I suppose.)

regards, mark hahn.

-
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/