From owner-freebsd-current@FreeBSD.ORG Mon Jul 7 06:34:48 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 D4F5437B401 for ; Mon, 7 Jul 2003 06:34:48 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 85EE643F85 for ; Mon, 7 Jul 2003 06:34:47 -0700 (PDT) (envelope-from mdcki@gmx.net) Received: (qmail 11609 invoked by uid 65534); 7 Jul 2003 13:34:46 -0000 Received: from pD9E2D21A.dip.t-dialin.net (EHLO gmx.net) (217.226.210.26) by mail.gmx.net (mp012) with SMTP; 07 Jul 2003 15:34:46 +0200 Message-ID: <3F097719.8030301@gmx.net> Date: Mon, 07 Jul 2003 15:35:21 +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: Thomas Dickey 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> In-Reply-To: <20030707123707.GA18750@saltmine.radix.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "Myron J. Mayfield" cc: Matthias Andree cc: current@freebsd.org cc: dickey@herndon4.his.com 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 13:34:49 -0000 Thomas Dickey wrote: > On Mon, Jul 07, 2003 at 02:23:25PM +0200, Marcin Dalecki wrote: > >>You know that file system name lookup is one of the most >>expensive system calls under UNIX? > > > stating the obvious is a clumsy rhetorical ploy (asking for agreement without > making a point). 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. I tought this was obvious?