/dev/shm

[Matthias Andree]

On Mon, 07 Jul 2003, Marcin Dalecki wrote:

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

Top data is not accurate (I though that was obvious ;-).

It's an obsolete snapshot the very moment it's printed to your console,
and I bet it changes as you read with a lot of implementations because
no-one wants to beat the big kernel lock on the process list just
because some user happens to run top, might be a nice DoS otherwise,
fork-bombing top...

If you want accurate data, use a kernel debugger with remote interface
and make sure the machine does nothing except servicing the debugger
interface.

> I tought this was obvious?

Why do I care? 0.58user 0.89system 1:00.91elapsed 2%CPU -- on a 266 MHz
Pentium-II, Linux 2.4, 5 years old, with 190 processes. The box idles
73% of the time it's up, there's _ample_ CPU power left.

-- 
Matthias Andree