From owner-freebsd-stable@FreeBSD.ORG Thu May 12 14:57:00 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 1458316A4D0 for ; Thu, 12 May 2005 14:57:00 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id B066C43D67 for ; Thu, 12 May 2005 14:56:59 +0000 (GMT) (envelope-from mkb@incubus.de) Received: from drjekyll.mkbuelow.net (p54AAD37C.dip.t-dialin.net [84.170.211.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 938842F450; Thu, 12 May 2005 16:56:58 +0200 (CEST) Received: from [IPv6:::1] (localhost.mkbuelow.net [IPv6:::1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j4CEwFLc002139; Thu, 12 May 2005 16:58:16 +0200 (CEST) (envelope-from mkb@incubus.de) Message-ID: <42836F07.1030100@incubus.de> Date: Thu, 12 May 2005 16:58:15 +0200 From: Matthias Buelow User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050509) X-Accept-Language: en-us, en MIME-Version: 1.0 To: noackjr@alumni.rice.edu 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> In-Reply-To: <42836B8F.607@alumni.rice.edu> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=6FF22C9F; url=http://www.mkbuelow.net/mkbkeys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org 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 14:57:00 -0000 Jonathan Noack wrote: > What happens if the command is long enough to overrun the screen? Is > the thread information truncated and lost? I believe this was the > argument for making a separate column for the thread info. How about leaving either SIZE or RES out, the one which makes less sense for typical use (probably SIZE which, afaik, is quite pointless in the presence of an overcomitting memory allocator, and the curious user could consult ps if he's really interested in that). mkb.