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

[William Lee Irwin III]

On Fri, Aug 27, 2004 at 02:24:12PM +0200, Roger Luethi wrote:
> Problems with /proc
> ===================
> The information in /proc comes in a number of different formats, for
> example:
> - /proc/PID/stat works for parsers. However, because it is not
>   self-documenting, it can never shrink, It contains a growing number
>   of dead fields -- legacy tools expect them to be there. To make things
>   worse, there is no N/A value, which makes a field value 0 ambiguous.
> - /proc/pid/status is self-documenting. No N/A value is necessary --
>   fields can easily be added, removed, and reordered. Too easily, maybe.
>   Tool maintainers complain about parsing overhead and unstable file
>   formats.
> - /proc/slabinfo is something of a hybrid and tries to avoid the
>   weaknesses of other formats.
> So a key problem is that it's hard to make an interface that is both
> easy for humans and parsers to read. The amount of human-readable
> information in /proc has been growing and there's no way all these
> files will be rewritten again to favor parsers.

These are many of the same issues raised in rusty's "current /proc/ of
shit" thread from a while back.


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. How many processes did you microbenchmark with?
I see no evidence that this will be a speedup with large numbers of
processes, as the problematic algorithms are preserved wholesale.


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