From owner-freebsd-current@FreeBSD.ORG Fri May 13 10:21:31 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 73C8E16A4CE for ; Fri, 13 May 2005 10:21:31 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9493643D46 for ; Fri, 13 May 2005 10:21:29 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j4DAJgVH018904; Fri, 13 May 2005 13:19:42 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j4DALIrG080020; Fri, 13 May 2005 13:21:18 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost)j4DALGrr080019; Fri, 13 May 2005 13:21:16 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 13 May 2005 13:21:16 +0300 From: Giorgos Keramidas To: Chuck Swiger Message-ID: <20050513102116.GD9642@orion.daedalusnetworks.priv> References: <20050512.220006.124086156.imp@bsdimp.com> <42847665.4030803@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42847665.4030803@mac.com> X-Mailman-Approved-At: Fri, 13 May 2005 11:59:10 +0000 cc: freebsd-current@freebsd.org cc: Matthias Buelow cc: "M. Warner Losh" 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 10:21:31 -0000 On 2005-05-13 05:41, Chuck Swiger wrote: > Since Giorgos is the one who seems to be the closest to actively > writing code, and has asked for feedback, well, I think his suggested > layout is an improvement, and I agree with these: First of all, thanks a lot for the feedback :-) > + The entire header line is limited to the window width too. > + The USERNAME column is hard-limited to 8 characters. > + The CPU/WCPU columns occupy the same space and can be toggled with > the 'C' keyboard command. > + When UID numbers are displayed, hitting 'u' will read a UID instead > of a username. > > 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. 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 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 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 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. I'll have to give a bit more of thought to this, but if I don't get anywhere near a form decision it may make sense to make the appearance of a THR column run-time configurable. > I'd be happier with a "#TH" column, and limiting the # of threads to > displayed to 999 or "+++", or some such. If we need to drop a column, > I'd much rather drop the "NICE" column and have a "#TH" column > instead. Ideally, all columns should be runtime configurable, much like ps(1) and its -o option. > (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. - Giorgos