[lkml]   [2004]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [0/2][ANNOUNCE] nproc: netlink access to /proc information
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.029 / U:1.636 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site