Re: /dev/shm

From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 07/08/03

  • Next message: Roderick van Domburg: "Reproducable panic with ida(4)" 
    Date: Tue, 08 Jul 2003 02:47:05 -0700
To: Marcin Dalecki <mdcki@gmx.net>

    Marcin Dalecki wrote:
    > Thomas Dickey wrote:
    > > On Mon, Jul 07, 2003 at 02:23:25PM +0200, Marcin Dalecki wrote:
    > >>You know that file system name lookup is one of the most
    > >>expensive system calls under UNIX?
    > >
    > > stating the obvious is a clumsy rhetorical ploy (asking for agreement without
    > > making a point).
    >
    > The point is that this is one of the reasons why the top command in
    > question takes a lot of relative CPU time under Linux. Some
    > "faster" versions of procps utils try to cache data but the trade off
    > is simply the fact that the results are not 100% accurate.
    > I tought this was obvious?

    Let's all agree that /dev/shm is an obvious lose that was put
    there for the POSIX cruft, and it's not really a necessary
    implementation detail. Mostly, I think it's there to support
    shared unnamed semaphores in process scope, when callers should
    really be using named semaphores for that type of sharing.

    Now ignoring all that, *all* "ps" programs operate on a snapshot
    of the system data, and rarely, if ever, accurately reflect what
    is really going on in the system. The FreeBSD sysctl approach
    to copying the data out using an array of structure entries is
    just as bad a hack; there are just different tradeoffs.

    The one really negative thing about the Linux approach is that
    it can't operate on a system dump image, like FreeBSD's "ps" can
    still do. Of course the FreeBSD version is ugly in that it has
    to carry around th libkvm code to do this -- we still haven't
    gotten our ELF acts together enough in both OS's to attach code
    and data sections that (effectively) would allow a program to
    use a kernel as a guaranteed-up-to-date-and-matching-libkvm. It
    would still have the drawback of being a data interface, but at
    least there would be only one interface, and it would solve the
    up-to-date problem that the sysctl interface was invented to
    solve, with the benefit of not having to carry around two sets
    of interfaces in the code.

    Meanwhile, the procfs overhead is really grotty for programs like
    "top"; it's not so bad for programs like "ps". The main problem
    it has is that it adds yet-another-API-that-must-be-supported for
    Linux ABI compatability.

    On the other hand, FreeBSD also has this tendency toward API
    growth in an uncontrolled fashion (as evidence, the three new
    system calls to support "setattr" from user space).

    -- Terry
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Roderick van Domburg: "Reproducable panic with ida(4)"