Re: [0/2][ANNOUNCE] nproc: netlink access to /proc information

[Roger Luethi <rl@hellgate.ch>]

On Fri, 27 Aug 2004 09:23:08 -0700, William Lee Irwin III wrote:
> These are many of the same issues raised in rusty's "current /proc/ of
> shit" thread from a while back.

The problems are not new. The driver stuff has been outsourced to /sysfs
in the meantime, though, and the information that is being added to
/proc these days is usually human-readable and a pain to parse.

> On Fri, Aug 27, 2004 at 02:24:12PM +0200, Roger Luethi wrote:
> > Another problem with /proc is speed. If we put all information in a few
> > large files, the kernel needs to calculate many fields even if a tool
> > is only interested in one of them. OTOH, if the informations is split
> > into many small files, VFS and related overhead increases if a tool
> > needs to read many files just for the information on one single process.
> > In summary, /proc suffers from diverging goals of its two groups of
> > users (human readers and parsers), and it doesn't scale well for tools
> > monitoring many fields or many processes.
> 
> There are more maintainability benefits from the interface improvement
> than speed benefits.

Agreed. That has been my initial motivation. Speed is a bonus.

> How many processes did you microbenchmark with?

Nothing worth mentioning. I have nothing in /proc space to compare
to. I was hoping someone would suggest a /proc based benchmark.

> I see no evidence that this will be a speedup with large numbers of
> processes, as the problematic algorithms are preserved wholesale.

It doesn't fundamentally change the complexity, but I expect the
reduction in overhead to be noticeable, mostly due to:
- no more string parsing.
- fewer system calls.
- fewer cycles wasted on calculating unnecessary data fields.

Roger