[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: dcache_rcu [performance results]
    On Mon, Nov 04, 2002 at 09:29:14AM -0800, Martin J. Bligh wrote:
    > > Clearly dcache_lock is the killer when 'ps' command is used in
    > > the benchmark. My guess (without looking at 'ps' code) is that
    > > it has to open/close a lot of files in /proc and that increases
    > > the number of acquisitions of dcache_lock. Increased # of acquisition
    > > add to cache line bouncing and contention.
    > Strace it - IIRC it does 5 opens per PID. Vomit.

    I just did, had the same reaction. This is ugly.

    It opens stat, statm, status, cmdline and environ apparently
    regardless of what will be in the ouput. At least environ
    will fail on most pids if you aren't root, saving on some of
    the overhead. It compunds this by doing so for every pid
    even if you have explicitly requested only one pid by

    Clearly ps could do with a cleanup. There is no reason to
    read environ if it wasn't asked for. Deciding which files
    are needed based on the command line options would be a

    I'm thinking that ps, top and company are good reasons to
    make an exception of one value per file in proc. Clearly
    open+read+close of 3-5 "files" each extracting data from
    task_struct isn't more efficient than one "file" that
    generates the needed data one field per line.

    Don't get me wrong. I believe in the one field per file
    rule but ps &co are the exception that proves (tests) the
    rule. Especially on the heavily laden systems with
    tens of thousands of tasks. We could do with a something
    between /dev/kmem and five files per pid.

    J.W. Schultz Pegasystems Technologies
    email address:

    Remember Cernan and Schmitt
    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 13:30    [W:0.040 / U:269.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site