From owner-freebsd-stable@FreeBSD.ORG Thu May 12 15:32:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1600D16A4CE for ; Thu, 12 May 2005 15:32:57 +0000 (GMT) Received: from olive.qinip.net (olive.qinip.net [62.100.30.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871FE43D68 for ; Thu, 12 May 2005 15:32:56 +0000 (GMT) (envelope-from ronald-freebsd8@klop.yi.org) Received: from ronald.echteman.nl (h8441134153.dsl.speedlinq.nl [84.41.134.153]) by olive.qinip.net (Postfix) with SMTP id 170EB18A9C for ; Thu, 12 May 2005 17:32:53 +0200 (MEST) Received: (qmail 18831 invoked from network); 12 May 2005 15:32:54 -0000 Received: from unknown (HELO localhost) (10.0.1.4) by ronald.echteman.nl with SMTP; 12 May 2005 15:32:54 -0000 To: freebsd-stable@freebsd.org References: <1115815807.8809.3.camel@buffy.york.ac.uk> <20050512103929.GB1320@orion.daedalusnetworks.priv> <200505121349.31508.dom@goodforbusiness.co.uk> <20050512131219.GB3107@orion.daedalusnetworks.priv> <42836B8F.607@alumni.rice.edu> <42836F07.1030100@incubus.de> <428372F7.1050209@alumni.rice.edu> <4283746E.6010109@incubus.de> Message-ID: Date: Thu, 12 May 2005 17:31:45 +0200 From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4283746E.6010109@incubus.de> User-Agent: Opera M2/8.0 (FreeBSD, build 1095) Subject: Re: Strange top(1) output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 15:32:57 -0000 On Thu, 12 May 2005 17:21:18 +0200, Matthias Buelow wrote: > Jonathan Noack wrote: > >> I think you will have a very hard time removing anything from top >> because someone will always pipe up and say, "I've been using >> since the days when computers were measured in >> MILLIhertz... *shaking fist*" Why not add an option to switch between >> SIZE and RES? Perhaps 'M'? > > Yeah well.. presented with 80-column space constraints, however, I'd > prefer to have a threads column rather than a virtual memory usage > column (especially when that "virtual memory" isn't a real resource > limit since the system is overcommitting, except when you set artificial > limits via ulimit etc.) What is so interesting about the number of threads of an application? I would add an option for use in the TOP env var or on the command line. -- Ronald Klop Amsterdam, The Netherlands