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.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
