lkml.org 
[lkml]   [2004]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [proc.txt] Fix /proc/pid/statm documentation
    On Fri, 06 Aug 2004 07:07:14 -0700, William Lee Irwin III wrote:
    > On Fri, 06 Aug 2004 05:11:18 -0700, William Lee Irwin III wrote:
    > >> Some of the 2.4 semantics just don't make sense. I would not find it
    > >> difficult to explain what I believe correct semantics to be in a written
    > >> document.
    >
    > On Fri, Aug 06, 2004 at 03:57:56PM +0200, Roger Luethi wrote:
    > > IMO this is a must for such files (and be it only some comments above
    > > the code implementing them). I'm afraid that statm is carrying too much
    > > historical baggage, though -- you would add yet another interpretation
    > > of those 7 fields.
    > > Tools reading statm would have to be updated anyway, so I'd rather
    > > think about what could be done with a new (or just different) file.
    >
    > Okay, could you write up a "specification" for what you want reported,
    > then I can cook up a new file or some such for you?

    Thanks for your offer. I really suck at communicating, it seems. I don't
    mind implementing my suggestion or writing documentation if there is a
    general agreement that this is the way to go. Currently, I am looking
    for suggestions and comments.

    My suggestion for /proc/pid/statm would be

    Field 0 := /proc/pid/status:VmSize
    Field 1 := /proc/pid/status:VmRSS
    Fields 2-6: 0

    That's really just cleaning up cruft and is trivial to implement.

    ============ Warning. Switching subject.
    Maybe I should have started a separate thread for that. Sorry about
    the confusion.

    I am also interested in a related problem -- finding a better way for
    tools to access process information. Preferably a generic way so we
    don't need to keep tools and kernel in sync forever. I have some ideas,
    but I don't know if they are acceptable as solutions (and if the problem
    actually exists as I see it).

    Most of the current problems with proc are related to tools: They don't
    like changes and some of them are very sensitive to resource usage
    (because they may make hundreds of calls per second on typical systems).

    If we want to facilitate the use of additional information in tools,
    I see two possible strategies:

    - Design a new solution that enables tools to discover the fields
    that are available and to ask for a subset (as I sketched out in my
    previous post). This would remove the need for inflexible solutions
    like statm.

    - Split proc information by new criteria: Slow, expensive items should
    not be in the same file as information that tools typically
    and frequently read. For instance, you could have status_basic,
    status_exotic, and status_slow. Even status_basic could have a format
    similar to /proc/pid/status, but would be shorter and contain only
    the most frequently used values (like statm today -- with all the
    problems that come with such a pre-made selection).

    Roger
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:3.464 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site