From owner-freebsd-current@FreeBSD.ORG Mon Jul 7 07:28:35 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D2CE37B401 for ; Mon, 7 Jul 2003 07:28:35 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BA43443F85 for ; Mon, 7 Jul 2003 07:28:33 -0700 (PDT) (envelope-from mdcki@gmx.net) Received: (qmail 29705 invoked by uid 65534); 7 Jul 2003 14:28:32 -0000 Received: from pD9E2D21A.dip.t-dialin.net (EHLO gmx.net) (217.226.210.26) by mail.gmx.net (mp015) with SMTP; 07 Jul 2003 16:28:32 +0200 Message-ID: <3F0983B2.5060500@gmx.net> Date: Mon, 07 Jul 2003 16:29:06 +0200 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en, pl, ru MIME-Version: 1.0 To: Matthias Andree References: <3F08B199.3050409@comcast.net> <3F08B79B.2040805@gmx.net> <20030707001443.GA1530@invisible-island.net> <20030707002347.GC5141@aurema.com> <20030706203440.D89894@vhost101.his.com> <3F08C4FD.8010107@gmx.net> <3F09663D.9020200@gmx.net> <20030707123707.GA18750@saltmine.radix.net> <3F097719.8030301@gmx.net> <20030707135459.GH10021@merlin.emma.line.org> In-Reply-To: <20030707135459.GH10021@merlin.emma.line.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: /dev/shm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 14:28:35 -0000 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.