lkml.org 
[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ps performance sucks

    First of all, sorry to break the threading. I didn't get
    a Cc: and the web archives drop most email headers. I'm
    going to respond to everyone in a big blob w/o attributions.

    > 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

    Done. You should be using procps-3.0.5 now. If you're not,
    an upgrade is called for. http://procps.sf.net/

    (tough luck if you're using some other ps)

    Nothing that parses the crap in /proc will ever be fast though.
    There's a patch for Linux 2.4.0 that some people might like:

    http://www.uwsg.iu.edu/hypermail/linux/kernel/0104.2/1720.html

    > Strace it - IIRC it does 5 opens per PID. Vomit.

    Nope, it does 2. Perhaps you're not running procps 3 yet?
    http://procps.sf.net/

    Of course if you do something like "ps ev" you need all 5.

    > 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.

    There are several ways to attack this.

    First of all, implement an open_read_close() syscall. Duh.
    I expect Hans Reiser would be delighted too. Maybe return
    a file descriptor if the file was too big or it blocked.
    Maybe provide some basic stat data atomically with the call.

    For per-task proc files, one file per kernel lock seems sane.
    I haven't looked at how many that would be, and of course it
    varies by kernel. So maybe it ends up not being exact; that's OK.

    > I think it's pretty trivial to make /proc/<pid>/psinfo, which
    > dumps the garbage from all five files in one place. Which makes
    > it 5 times better, but it still sucks.

    Well, not all the garbage! It'd be nice to have the popular
    stuff in a file similar to /proc/*/stat. That would be what ps
    needs to support these options: -f -l -F l u v j -j -ly -lc
    plus "top". (not counting the process name or args though)

    > You could take a more radical approach. Since the goal of such
    > a psinfo file would be to accelerate access to information
    > that's already available elsewhere, you can do away with many
    > of the niceties of procfs, e.g.
    >
    > - no need to be human-readable (e.g. binary or hex dump may
    > make sense in this case)

    As long as you expand everything to the biggest data type that
    could ever be used, binary is wonderful. Make the ABI be 64-bit
    for almost everything, with proper alignment of course. Somebody
    slap the person who put a 32-bit ino_t in the latest stat syscall.

    > First write says "pid,comm". Internally, this gets translated
    > to 0x8c+0x04, 0x2ee+0x10 (offset+length). Next read returns
    > "pid 4,comm 16" (include the name, so you can indicate fields
    > the kernel doesn't recognize). Then, kmalloc 20*tasks bytes,
    > lock, copy the fields from struct task_struct, unlock, let the
    > stuff be read by user space, kfree. Adjacent fields can be
    > optimized to single byte strings at setup time.

    If you're going to do that, then specify stuff via the filename:
    /proc/12345/hack/80basic,20pids,20uids,40argv,4tty,4stat

    Not that I care for dealing with the above!

    >> sgid country
    >> * real killer: you think Albert would fail to produce equally
    >> crappy code and equally crappy behaviour? Yeah, right.
    >
    > Well I think Rik and I can handle it in our tree :)

    You guys can't even get BSD process selection right.

    If necessary I could fix a few spots needed for setgid usage.
    I'd rather not need to do so, because then yet another chunk
    of non-kernel code is making security decisions.

    > * device is not network-transparent - even in principle

    ROTFL. What a fantasy. You damn well know /proc isn't either.
    If you can hack /proc to be exportable, you can damn well do
    the same for a device file. You won't be using NFS for this.
    I think Mosix already has a shared /proc anyway; an ioctl() is
    a simple matter of writing a little ugly code.

    > And i'd still keep environ seperate. I'm inclined to think
    > ps should never have presented it in the first place.
    > This is the direction i (for what it's worth) favor.

    Yeah, well that's BSD compatibility for you. Printing the
    environment might actually be useful if you could pick just
    the fields you wanted: ps -eo pid,stat,.DISPLAY,comm

    Useful? Like that notation?

    > Well if we want to be gross and efficient, we could just compile
    > a kmem-diving dynamic library with every kernel compile and stick
    > it in /boot or somewhere. Mildly less extreme is a flat index file
    > for the data you need a la System.map. Then just open /dev/kmem
    > and grab what you want. Walking the tasklist with no locking would
    > be an interesting challenge, but probably not insurmountable.
    > That's how things like ps always used to work IIRC.

    Yep, that's gross and efficient for sure. The dynamic library idea
    fixes a major problem; BSD "top" is always breaking due to kernel
    differences on Solaris and FreeBSD.
    -
    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 13:30    [W:0.026 / U:1.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site