Marcin Dalecki mdcki at gmx.net
Mon Jul 7 07:28:35 PDT 2003

Matthias Andree wrote:
> 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,

Obsolete and never accurate are two different things. You know
every information is obsolete the time it is recived.

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

Well once in a former live I was administering some servers over sometimes
slow lines. And if they where bogged down by actual *load* it was sometimes
really really very inconvenient to have no real chance at getting a quick
overview of the processes running there and causing the problem becouse top
didn't even get a chance to show up due to the hefty IO load it was causing.
If the box is idle I don't really care about the load as much as you don't care. 
This is something that was never a problem on any *BSD or Solaris box I had to
deal with thus far.

More information about the freebsd-current mailing list