From owner-freebsd-current@FreeBSD.ORG Fri May 13 11:17:48 2005 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 3064716A4CE for ; Fri, 13 May 2005 11:17:48 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B408B43D5E for ; Fri, 13 May 2005 11:17:47 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 2AAB65C74; Fri, 13 May 2005 07:17:47 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57738-09; Fri, 13 May 2005 07:17:45 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) by pi.codefab.com (Postfix) with ESMTP id 681995C50; Fri, 13 May 2005 07:17:45 -0400 (EDT) Message-ID: <42848CD4.50501@mac.com> Date: Fri, 13 May 2005 07:17:40 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <20050512.220006.124086156.imp@bsdimp.com> <42847665.4030803@mac.com> <20050513102116.GD9642@orion.daedalusnetworks.priv> In-Reply-To: <20050513102116.GD9642@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@freebsd.org Subject: Re: Strange top(1) output 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: Fri, 13 May 2005 11:17:48 -0000 Giorgos Keramidas wrote: > On 2005-05-13 05:41, Chuck Swiger wrote: [ ... ] >> The only thing I *don't* like is splatting the # of threads onto the >> end of the process name, seperated by a slash: that makes it >> remarkably hard to read. > > I see. > > This is one of those things that you either love or hate, I guess. > Somebody *did* suggest it while we had problems with the THR column > being too wide and pushing COMMAND out of the visible area, so I tried > to use prstat on Solaris 10 for a while to see how things work out. Maybe we could use this space for longer than 8-char usernames, especially if the thread count is the usual single digit? > The output format of prstat is: > > 1 2 3 4 5 6 7 8 > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > +-------------------------------------------------------------------------------- > | PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID > | 313 daemon 6448K 5584K sleep 58 0 0:11.30 0.2% snmpd/5 > | 3817 root 9016K 6640K sleep 58 0 0:00.08 0.1% cfailover/1 > | 7366 keramida 4240K 3568K cpu1 58 0 0:00.00 0.1% prstat/1 > | 7335 root 3904K 2464K sleep 58 0 0:00.00 0.1% sshd/1 [ Ohgod. Mozilla won't let me reformat this quoted text without making it un-magic and wrapping it. Lemme leave it as it is and hope for the best. ] > The format of our top, to make comparisons easier is: > 1 2 3 4 5 6 7 8 > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > +-------------------------------------------------------------------------------- > | PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > |54842 root 1 8 0 2364K 1884K wait 0:09 10.91% 10.69% sh > | 762 keramida 1 96 0 82432K 31280K select 4:53 0.00% 0.00% Xorg > |65426 keramida 4 20 0 44240K 34152K kserel 4:12 0.00% 0.00% firefox-b > | 814 keramida 1 96 0 6188K 4424K select 1:06 0.00% 0.00% wmaker There's four blanks there, so one could handle usernames up to 11 characters long. Or else remove the double-space between USERNAME and THR. We could reclaim another 2 spaces between STATE and TIME, as the overwhelming majority of states seem to be 6-chars long, as you note below. FWIW, top on Solaris is: > 1 2 3 4 5 6 7 8 > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > +-------------------------------------------------------------------------------- > | PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND > | 27956 chuck 1 0 0 1808K 1256K cpu/3 0:00 0.73% top > | 208 root 1 58 0 11M 11M sleep 312:46 0.06% se.sparcv9.5.8 > | 1 root 1 58 0 880K 360K sleep 52:08 0.00% init > | 194 root 14 56 0 64M 59M sleep 15:31 0.00% nscd I would zap NICE, and shrink TIME somehow, maybe using a human-readable format. If a process is nice'd, do what ps does (used to do?) and put a "<" or ">" in the space after PRI, which already displays the effective priority of the task, anway. Including the impact of nice as well as the scheduler's dynamic readjustment.... [ ... ] > The main differences, minus reordering of the fields are: > > - Our STATE column is 8 columns wide, while on prstat it uses 6 > - Our TIME column is 5 characters wide vs. prstat's 9 > - We have THR in a column vs. prstat which uses command/N > - We have both CPU and WCPU > - SIZE and RSS in prstat are 1 column shorter I'd be happier to shrink them and use a "dh -H" style readout, otherwise I agree with displaying only one of CPU and WCPU. Top is only an approximation or fixed sampling of dynamicly changing stuff, anyway-- the difference between the two isn't worth the space it uses. > The THR column seems a bit of waste in retrospect, because depending on > the workload of the system it may have just one column of useful data. Agreed. The question to answer, is how should one display the busiest threads of a process usefully in the top display? Figuring that one out would be useful to answering other questions about what top should look like. >> (Which is fine, curses does a lot of hard work that I'm just as happy to >> let it figure out.) > > Unfortunately, the current top uses very few of the features that a full > blown curses implementation would have. Curses by slow accumulation, rather than curses by design? Ick. :-) -- -Chuck PS: I would also vote for changing nothing in terms of adding or removing columns, just zapping the username length check, and try to squeeze the whitespace down a little to make more room for the COMMAND field.