Re: /dev/shm

From: Marcin Dalecki (mdcki_at_gmx.net)
Date: 07/07/03

  • Next message: Michal Suszko: "buildkernel ULE related breakage" 
    Date: Mon, 07 Jul 2003 16:29:06 +0200
To: Matthias Andree <matthias.andree@gmx.de>

    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.

    _______________________________________________
    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: Michal Suszko: "buildkernel ULE related breakage"