Date: Wed, 20 Feb 2013 22:26:47 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andrey Zonov <zont@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r246033 - head/usr.bin/systat Message-ID: <20130220220256.X856@besplex.bde.org> In-Reply-To: <5107BC87.4080403@FreeBSD.org> References: <201301281257.r0SCvhhv071414@svn.freebsd.org> <20130129003913.G2698@besplex.bde.org> <5107BC87.4080403@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jan 2013, Andrey Zonov wrote: > On 1/28/13 6:51 PM, Bruce Evans wrote: >> On Mon, 28 Jan 2013, Andrey Zonov wrote: >> >>> Log: >>> - Show page faults requiring I/O on vmstat display. >> >> No space is available there for showing it. > > Yep, you're right. >>> + mvprintw(VMSTATROW, VMSTATCOL + 9, "ioflt"); >> >> Putting it first unsorts the fields a bit and makes the diff large. >> >> It is not documented in the man page. > > Fixed in attached systat1.patch.txt. OK. >> ... >> "buf" is even more useless with zfs. So are some of the other fields >> ... > > I totally agree with you, 'buf' should go away from systat and top. I > removed 'buf' from systat. Please review systat2.patch.txt. I'd just like it to be replaced by a useful buf field someday. Since the field in row 23 (starting at row 0) is now useful, omitting it is not so good so I I agree with your patch removing the special code to avoid printing it on 24-row terminals. > To count 'disk cache' we have to add new counter which should track all > pages with OBJT_VNODE type. It doesn't look hard to implement this. I > wrote utility [1] which allows me to inspect memory and find what is in > disk cache. I think I would like at least 2 fields: - total disk space mapped in VMIO buffers - total disk space mapped in the buffer cache. > I also found that %ozfod is not useful for me and I removed it to not > mangle 'free' on 24-line terminals (systat3.patch.txt). Certainly no space is available for the luxury of both ozfod and %ozfod. That would also allow leaving buf and its 24-column support alone. Only 3 fields would move relative to the old version (not just 1 field changing for swapping %ozfod with the new field, since you want to put the new field first). Are the other fields in the best order? I think they are. If not, it would be good to move some when adjusting all the row numbers. > Thanks for comments! > > [1] https://github.com/z0nt/meminfo/ Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130220220256.X856>