Re: /dev/shm

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