[procps] Re: A rainy days effort
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Sun, 4 Mar 2012 09:49:56 -0600
On Mar 4, 2012, at 4:22 AM, Jim Warner wrote:
> Below is a summary of all top bugs and their status.
...
> ----------------------------------------------------- FIXED
> #454786, top: Use M, G or even T instead of K for better readability
> Fixed (sort of) with procps-ng. Now top just uses a single instance of the
> memory suffix.
Sorry...
This was not fixed in procps-ng and should remain a wishlist item.
The author was referring to numbers that were too big because scaling didn't
begin soon enough. Now we've worsened things from his perspective with the
following:
top: postpone the switch from Kb to Mb in summary display
commit 95f22017309f0025c724258335cf586b1d939e68
On my Apple Mac OS X version of top, I have user controlled progressive scaling
(from bytes through Kb, Mb, Gb and Tb) for all task related memory
fields/columns. That port also provides dual width memory columns which are
set automatically depending on SIGWINCH or manually controlled by the user.
For linux top, I could introduce user controlled memory scaling for at least
the summary area and maybe the task area too, as interactive commands. But the
obvious choice of 'S' or 's' conflicts with the 'cumulative time' or 'update
interval' commands.
Maybe it's time to reevaluate all top key assignments and finally get rid of
those very-old-top sort compatibility keys (A, M, N, P and T). And, do we
really need 's' (sleep) as an alias for 'd' (delay)?
Anyway, would scaling in the linux version of top be a worthwhile addition?
Regards,
Jim
Other related posts:
