Commit Graph

65 Commits

Author SHA1 Message Date
Craig Small
b31ac2dcce free: Show single line statistics
Added the -L --line option to free to show a small
set of memory statistics on a single line of 80 characters.
Largely based on the work of @Ulenrich1 and updated to
the new API.

References:
 procps-ng/procps#156

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-05-02 20:32:38 +10:00
ed neville
4a315c9230 Store sec and usec in terms of usec
Rather than attempt to convert usec to sec with division, add both
together and then divide.

This reduced the rounding errors on my system.
2023-05-02 09:08:37 +00:00
hdzhoujie
833cdc64f0 top: added 'guest' tics when multiple cpus were merged
The 'guest' tics are added in the
sum_tics function, but when multiple
cpus are combined for display, the
'guest' tics are not added cumulatively
in the sum_unify function.

signed-off-by: zhoujie <zhoujie133@huawei.com>
2023-04-20 09:27:19 +08:00
Craig Small
1f910eeb0e Fix test for double test
References:
  issue procps-ng/procps#271
2023-03-21 22:22:33 +11:00
Jim Warner
bb7e161d5a top: address the missing 'guest' tics for summary area
Well this is embarrassing. After repeatedly flogging a
horse (represented by issue #274) I was certain it was
dead. But, it turns out that the darn thing yet lived.

In fact, the bug that was patched was not even the one
the poster experienced. Now merge request #173 finally
penetrated my foggy brain and explicated the real bug.

Since forever (linux 2.6), top has ignored those guest
and guest_nice fields in /proc/stat. When many virtual
machines were running that overhead went unrecognized.

So, this commit simply adds those tics to the 'system'
figures so that it can be seen in text or graph modes.

Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/173

https://gitlab.com/procps-ng/procps/-/issues/274
. Mar 2023, avoid keystroke '%Cpu' distortions
commit 7e33fc47c6

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-03-21 22:11:29 +11:00
Jim Warner
411eaa1aa7 top: restore a commit which had been reverted in error
Please do not look at this change and especially don't
look at that commit message for the patch shown below.

[ that way you won't notice I misinterpreted 'H' for ]
[ an 'h' when this logic was reversed as 'redundant' ]

Reference(s):
commit 7e33fc47c6

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-03-21 22:11:29 +11:00
Jim Warner
7e33fc47c6 top: avoid '%Cpu' distortion resulting from keystrokes
Like a line from the movie Cool Hand Luke: "what we've
got here is failure to communicate"; well that was me!

Finally, I got a handle on the issue referenced below.

At first, it seemed inappropriate to try comparing cpu
percentages as reported by different top versions. And
even more so when they are invoked many seconds apart.

As it turns out, this issue had nothing to do with the
specific processor. Nor did it involve two versions of
top running simultaneously using the same delay value.
Rather, it concerns keyboard input and several changes
which were made last year in commits referenced below.

They were prompted by development of the 'Ctrl' bottom
window feature. Initially, if transitioning from a big
window to a small window portions of the former window
remained visible until the next refresh. A solution to
that led to a flaw when resizing top. Fixing that then
created a race condition with full screen replacement.

The net effect of all those changes was to distort the
cpu percentage value for the processor on which top is
dispatched to service user input. It arose because the
new frame was begun immediately, yielding few 'ticks'.

[ when fewer ticks are accumulated the potential for ]
[ distortion increases. As an example, hold some key ]
[ then watch cpu percentages (works best in graphs). ]

[ while any version of top will show distortions for ]
[ the above experiment, a v4.0.0 top will be greater ]
[ and %cpu is distorted even for a single keystroke. ]

So, to restore proper 3.3.17 keystroke behavior, we'll
revert parts of the first 3 commits shown below. Plus,
the 4th commit will be entirely reversed as redundant.

Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/274

. Sep, 2022 - avoid potential 'BREAK_screen' race
commit 3e5016c289
. Sep, 2022 - fix improper sigwinch behavior
commit 9d9993708b
. May, 2022 - made more responsive to kdb input
commit 3ea1bc779f
. turn bottom window off with additional key
commit 3f068a66c8

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-03-09 20:16:47 +11:00
Jim Warner
cbbe8fe324 top: ensure an EXIT_FAILURE with bad command line args
When getopt usage was added (plus long options) in the
patch shown below, top no longer returned EXIT_FAILURE
when the error message was generated by getopt itself.

This commit will restore the proper behavior no matter
who might issue a command line argument error message.

Thanks to Bastian Bittorf for discovering this buglet.

Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/273
. sep, 2021 - getopt with long form args
commit c91b371485

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-03-08 22:18:39 +11:00
Thorsten Kukuk
cced1e49ef w: make sure null terminated ut_* strings are used
strncpy does not null terminate a string if it has the maximal length.
Use always the null terminated variants for ut_user and ut_line.

Signed-off-by: Thorsten Kukuk <kukuk@suse.com>
2023-03-08 07:30:56 +11:00
Craig Small
8c81808de0 pgrep: Use only --signal option for signal
When pgrep was used to match on signal, it makes sense to use
the same signal parsing code as pkill. Unfortunately the
"find the signal" part is a little too enthusaistic about what a
signal is, meaning

pgrep -u -42

fails because the signal becomes "42" and then there is no UID.

This is a bit sad for pkill but has been that way for a long
time. For pgrep this is new so now only the long form
pgrep --signal <X>
will work.

In addition, when using --signal if pgrep/pkill couldn't work
out what the signal was it just silently ignored it. It now
complains and aborts.

References:
 https://bugs.debian.org/1031765
 commit 866abacf88
2023-03-01 17:35:14 +11:00
Craig Small
9b2f49166b tests: Dont compare floats with ==
Comparing floats with == is bad and I should feel bad I did this.
The problem is if something is close to, but not quite the exact
same fails tests.

I have used an epsilon of 1 because we don't care about accuracy,
just that the function works well enough.

References:
 issue procps-ng/procps#271
 https://how-to.fandom.com/wiki/Howto_compare_floating_point_numbers_in_the_C_programming_language

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-03-01 17:20:42 +11:00
Jim Warner
3727cf4478 misc: Update the copyrights for the ps and top sources
This patch just follows Craig's lead for the remaining
ps and top program files and associated man documents.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-02-08 16:53:04 +11:00
Craig Small
8fcfb01a81 misc: Update the copyrights of files
The copyrights of the source files were all out of date and were not
the same format. This has been corrected. The source of the authors
was examining the git log for each file.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 21:09:48 +11:00
Jason Cox
848be2b1e2 pgrep: make --terminal respect other criteria
In some cases the --terminal option to pgrep will cause all processes
matching the terminal to be output, even if other criteria would exclude them.
Specifically, I noticed that it overrides the --runstates option.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-25 20:34:21 +11:00
Jim Warner
a4add59024 top: squeeze namespace provision (^P) onto help screen
Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-24 12:15:19 +11:00
Jim Warner
6b71148840 top: restore tab highlight for ^L and ^P bottom window
With the commit shown below a BOT_PRESENT constant was
introduced. Unfortunately it was defined in a way that
disable ^L (message log) and ^P (namespaces) highlight
when using the tab key. This patch fixes such an oops.

Reference(s):
. Jan, 2023 - lessen 'bottom window' overhead
commit 28f44729da

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-24 12:15:19 +11:00
Jim Warner
f9afbabce7 misc: eliminated some instances of trailing whitespace
Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-24 12:15:19 +11:00
Craig Small
2532b5d2dd ps: Add configurable date format for lstart field
The lstart field has been converted to use the strftime()
function so that it uses the locale. A new option -D
allows the user to define the format that would want this
field to show.

This may mean the field will be longer than it should be,
especially for French locales and the user defined field,
but the field length can be specified too.

---

This commit started off making all the relevant fields use the
locale correctly so it could solve #226 as well. The issue
is there an implied restriction (or not) around
strftime("%b") and probably strftime("%a") for abbrievated month
and day names respectively.

English, and some/most other languages put an additional
restriction that all abbreviations are 3 characters long.
The problem is, not all languages do this.

French is a good example:
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.

Maybe strip the . at the end?
 That helps for some months, not all
Maybe take the first three characters?
 Several wide languages will have big issues
Maybe convert wide, get wcslen then use that.
 Even after that June "juin" and July "juil" are both "jui".

So, anything that uses the month (bsdstart,start) use ctime which
doesn't use locale. That solves the length issue.

stime does, which means it has this issue but its been like that
for years. You get stuff like this:

janv.13 482261
00:00 1151918
 2022 1458628
06:12 1957584

The only way to fix that would be to
 a)Make the field two characters longer
 b)Convert it back to ctime() which means everyone else
   loses.

This could have be oh-so easy if everyone made %b and %a three
(wide) characters everywhere.

References:
 procps-ng/procps#228
 procps-ng/procps#226

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-18 17:46:06 +11:00
Qin Fandong
0a5ccbdd42 vmstat: precision issues in unitConvert()
Fix conversion errors due to precision issues in function unitConvert

For example: unitConvert(98720620) will return 98720624, not 98720620.

Because we do (unsigned long)(float)98720620 in function unitConvert
and this is wrong! We should do (unsigned long)(double)98720620 here.

Signed-off-by: Craig Small <csmall@dropbear.xyz>

References:
 procps-ng/procps!75
2023-01-18 17:02:53 +11:00
Sanskriti Sharma
68e2c0fc53 vmstat: Fixed initial si,so,bi,bo,in & cs values
In the default display option, the first line of stats output in the
above mentioned columns was incorrect.

References:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668580
 procps-ng/procps!74
 procps-ng/procps#15

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-18 16:56:24 +11:00
Justin Gottula
8a65a304e0 watch: Fix buggy line-deletion behaviour with --no-linewrap
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.

Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.

After some fiddling around, the exact problematic behavior appears to be
as follows:
 1. Lines which would have wrapped (more than $COLUMNS chars long) are
    handled correctly.
 2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
    printed; but then the next line is *not* printed! For long sequences
    of non-wrap-length lines, you get an every-other-line-is-visible
    sort of effect.

The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.

However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.

Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.

References:
 procps-ng/procps!157

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-18 16:46:52 +11:00
Craig Small
b2bfd76b06 watch: add -r to not rexec on terminal resize
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.

References:
 procps-ng/procps!125
 procps-ng/procps#190
2023-01-17 20:45:48 +11:00
Craig Small
5f4074a250 watch: Pass through bell
Based upon merge request 104, closes #174

References:
 procps-ng/procps!104
 procps-ng/procps#174
2023-01-17 16:59:00 +11:00
Jan Pazdziora
5baf1e6226 w: add --pids option to display the pid of the login and best processes. 2023-01-15 04:15:32 +00:00
Chris Down
866abacf88 pgrep: Support matching on the presence of a userspace signal handler
In production we've had several incidents over the years where a process
has a signal handler registered for SIGHUP or one of the SIGUSR signals
which can be used to signal a request to reload configs, rotate log
files, and the like. While this may seem harmless enough, what we've
seen happen repeatedly is something like the following:

1. A process is using SIGHUP/SIGUSR[12] to request some
   application-handled state change -- reloading configs, rotating a log
   file, etc;
2. This kind of request is deprecated and removed, so the signal handler
   is removed. However, a site where the signal might be sent from is
   missed (often logrotate or a service manager);
3. Because the default disposition of these signals is terminal, sooner
   or later these applications are going to be sent SIGHUP or similar
   and end up unexpectedly killed.

I know for a fact that we're not the only organisation experiencing
this: in general, signal use is pretty tricky to reason about and safely
remove because of the fairly aggressive SIG_DFL behaviour for some
common signals, especially for SIGHUP which has a particularly ambiguous
meaning. Especially in a large, highly interconnected codebase,
reasoning about signal interactions between system configuration and
applications can be highly complex, and it's inevitable that on occasion
a callsite will be missed.

In some cases the right call to avoid this will be to migrate services
towards other forms of IPC for this purpose, but inevitably there will
be some services which must continue using signals, so we need a safe
way to support them.

This patch adds support for the -H/--require-handler flag, which matches
on processes with a userspace handler present for the signal being sent.

With this flag we can enforce that all SIGHUP reload cases and SIGUSR
equivalents use --require-handler. This effectively mitigates the case
we've seen time and time again where SIGHUP is used to rotate log files
or reload configs, but the sending site is mistakenly left present after
the removal of signal handler, resulting in unintended termination of
the process.

Signed-off-by: Chris Down <chris@chrisdown.name>
2023-01-15 04:05:40 +00:00
Jim Warner
1db14dafd9 top: include the '5' toggle on the primary help screen
When the p/e-cores support (via the '5' key) was added
in the patch referenced below, I intentionally omitted
that key from the top primary help screen. This seemed
appropriate since it only applied to select Intel cpus
and, besides, that screen was getting kind of crowded.

[ it remains an objective to fit on a 80x24 terminal ]

Upon reflection, I found a way to squeeze it into that
help screen and have decided to included it. Hopefully
its presence will encourage use of top's new provision
on any Intel platforms that distinguish between cores.

Reference(s):
Sep, 2022 - exploit p/e-cores provision
commit 00f5c74b1b

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-15 15:02:39 +11:00
Jim Warner
28f44729da top: lessen overhead when 'bottom window' isn't active
In the commits referenced below special code was added
to make the bottom window sticky and fix the bug after
'Cap_nl_clreos' was traded for the 'Cap_clr_eol' loop.

However, there's always major overhead associated with
interacting with a terminal. So we'll only abandon the
single 'Cap_nl_clreos' putp in favor of repeated calls
with 'Cap_clr_eol' when a bottom window isn't present.

Reference(s):
. May, 2022 - bottom window batch bug fix
commit 793f3e85ae
. May, 2022 - bottom window made sticky
commit 0f2a755b0b

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-15 15:02:39 +11:00
Jim Warner
548c6a05ba top: tweak whitespace in some #defines for consistency
Please, do not look at the actual changes made by this
commit. Trust me they will vastly improve performance.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2023-01-15 15:02:39 +11:00
Ingo Saitz
7e24816538 vmstat: Update memory statistics
vmstat <n> would update most fields, but the memory statistics
were only fetched the first time.

References:
 https://bugs.debian.org/1027963

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-06 13:30:39 +11:00
Craig Small
dd3cb0892d ps: Correct BSD c option
procps 3.3.17 the c option changed the command/args field
to cmd but this got removed as part of newlib

Functionality is back in with a test case.

References:
 https://bugs.debian.org/1026326

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-12-19 16:50:12 +11:00
Craig Small
f7a33746f8 skill: Restore the -p flag functionality
When the skill program was ported to the new API the code to filter
on PID, used by the -p option, was missed. It is now restored.

References:
 https://bugs.debian.org/1025915
2022-12-12 16:46:36 +11:00
Chris Down
c92da2adc5 pkill: Don't show --echo twice
Commit c8384e682c ("pgrep: add pwait") changed from the old i_am_pkill
logic, but mistakenly missed a break in the pkill case. This results in
showing -e/--echo twice when running `pkill -h'.

Signed-off-by: Chris Down <chris@chrisdown.name>
2022-11-09 10:51:12 +00:00
Fabrice Fontaine
17f94796a9 fix pifd_open check
Replace AC_CHECK_FUNC by AC_CHECK_FUNCS otherwise HAVE_PIDFD_OPEN will
never be defined resulting in the following build failure if pidfd_open
is available but __NR_pidfd_open is not available:

pgrep.c: In function 'pidfd_open':
pgrep.c:748:17: error: '__NR_pidfd_open' undeclared (first use in this function); did you mean 'pidfd_open'?
  748 |  return syscall(__NR_pidfd_open, pid, flags);
      |                 ^~~~~~~~~~~~~~~
      |                 pidfd_open

This build failure is raised since the addition of pwait in version
3.3.17 and
c8384e682c

Fixes:
 - http://autobuild.buildroot.org/results/f23a5156e641b2ebdd673973dec0f9c87760c688

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
2022-11-09 10:15:05 +00:00
Craig Small
d99c213af9 w: Show time with TIME_BITS=64 on 32bit env
Thanks to @kabe-gl for this patch.

w command shows ????? for LOGIN@ column when compiled on 32bit environment with -D_TIME_BITS=64.

References:
 #256

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-11-09 21:02:09 +11:00
Jim Warner
2647eb57da top: also adapted to absent 'core id' in /proc/cpuinfo
Just as our library was made responsive to a potential
missing 'core id', the top program should also change.

That's because he has his own PRETENDECORE #define and
if that was activated on a platform without 'core id',
the 'CpP' notations would have otherwise been omitted.

Reference(s):
. Oct, 2022 - library fix for missing 'core id'
commit b89e3230b2

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-30 21:18:30 +11:00
Jim Warner
57774f0332 top: restore missing support for 'MEMGRAPH_OLD' define
When support for graphs was refactored, in that commit
referenced below, the logic for our 'MEMGRAPH_OLD' was
lost while the #define itself remained in the .h file.

Faced with deleting the #define or restoring the logic
I chose the latter. Thus, if one wanted to be reminded
how overstated 'used' memory once was, it can be done.

Reference(s):
. Sep, 2022 - refactored graph support
commit 2d5b51d1a2

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-16 19:56:19 +11:00
Jim Warner
244f2b33f2 top: whack an obsolete string plus its associated code
When long command line options were introduced, in the
patch shown below, the string associated with the enum
'WRONG_switch_fmt' became obsolete. However, that enum
and its string were never removed. Well, now they are.

Reference(s):
. Sep, 2021 - getopt and long cmdline options
commit c91b371485

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-16 19:56:19 +11:00
Jim Warner
ab05a3785f top: fix a flaw in excluding a string from translation
In that commit referenced below, I removed the command
line help text from any translation so the TP wouldn't
delay our 4.0.1 release any further. In looking to the
future, when we might be able to reverse that, I found
gettext tools blocking use of the compile conditional.

They are too primitive for the original approach so we
must modify that exclusion mechanism hack accordingly.

____________________________excerpted program comments

The provision excluding some strings is intended to be
used very sparingly. It exists in case we collide with
some translation project person in a position to delay
a future release over his or her personal preferences.

If it's ever enabled, it will produce a fatal compiler
error as our only option since those gettext tools are
far too primitive to be influenced with a conditional.
They always ignore a '_X()' macro no matter its state.

Reference(s):
commit 8a368bfb05

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-06 22:05:36 +11:00
Jim Warner
8a368bfb05 top: enable exclusion of some strings from translation
The provision excluding some strings is intended to be
used very sparingly. It exists in case we collide with
some translation project person in a position to delay
a future release over his or her personal preferences.

(it's currently used only on v4.0.1 command line help)

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-04 10:57:34 +11:00
Jim Warner
c7568b28fb top: always validate that p-core/e-core identification
Prior to this commit, when the '5' key was struck, top
would check for the presence of e-cores just one time.

That meant if a some cpu was brought online, and it in
turn exposed a new e-core after top has started, users
needed a top restart to activate the  new '5' feature.

So, now we'll check for any e-cores with each '5' key.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-04 10:57:34 +11:00
Jan Rybar
3ea211fab8 free: --si changes base of default output 2022-09-28 07:57:03 +00:00
Jim Warner
00f5c74b1b top: exploit that library p-core/e-core identification
I sure hope we won't disappoint the library with these
changes since we're only exploiting one of the two new
enumerators that the immediately prior patch provided.

Now top will be able to offer a visual clue as to each
cpu (thread actually) core association. Is it a P-core
offering multiple threads or a single threaded E-core.

We'll accomplish this feat with a subtle change to the
states portion ('t' toggle) of the summary area. Where
before processors were represented as 'Cpu', they will
now be displayed as 'CpP' (P-core) and 'CpE' (E-core).

[ assuming that new '5' command toggle has been used ]

There are also new provisions for filtering those cpus
by their core type association via the new '5' toggle.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-28 17:30:56 +10:00
Jim Warner
3e5016c289 top: avoid any potential race involving 'BREAK_screen'
When that 'Bottom' window was being finalized, an enum
of BREAK_screen was added to the Frames_signal values.
This was done so some full screen replacement function
could flag the need for that bottom window to go away.

Around that same time, top was made more responsive to
keyboard input so that residual portions of a previous
bottom window would not linger until the next refresh.
This happened if going from a larger (^N, environment)
bottom window to some smaller window (^P, namespaces).

The combined effect of these changes was to create the
potential race condition this commit addresses. If the
user encountered a SIGWINCH while on any of those full
screen replacement displays (help, fields mgmt, etc.),
endless redraws would occur. A ^C was the only option.

Henceforth we will protect against any redraw loops by
clearing Frames_signal each time a redraw is required.

[ along the way, we'll make the 'q' key work on that ]
t secondary 'windows' help screen as it should, even ]
[ though it is not documented on that screen itself. ]

Reference(s):
. May, 2022 - more responsive to keyboard input
commit 3ea1bc779f
. May, 2022 - maybe force the bottom window off
commit d66c1f39b5

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
5f9185e087 top: try avoiding the edge of a 'divide by zero' cliff
Darn, after testing on some older, out of date distros
I was embarrassed to find some awful code I created in
the commit shown below. I was rewarded with some 'nan'
floating point values and 'inf' computational results.

Reference(s);
. a missed opportunity to repent
commit 5c5bff392b
. true source of my original sin
commit 2d5b51d1a2

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
124f26a423 top: fix 'TOG4_MEM_1UP' if two abreast summary display
If one per line display of Mem/Swap data was forced by
this #define, screen width was not fully exploited for
graph mode. Rather, those graphs were scaled just like
they would be if aligned with a nonexistent separator.

With this commit, those graphs will expand to fill the
screen width (or be limited by the maximum of '100' ).

[ and in unrelated news a variable used in do_memory ]
[ was changed for consistency. it doesn't affect the ]
[ the results since a part1 of swap was always zero. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
602146a623 top: enhance memory graphs two abreast summary display
This patch introduces a new #define TOG4_MEM_FIX which
serves to turn off the new feature it also implements.

The feature, on by default, provides a flexible memory
graph approach which strives to always keep its visual
separator in alignment with cpu separators seen above.

Below is a summary of the algorithm implementing this:

1) First, ascertain the widest graph which corresponds
to the largest number of cpu graphs but doesn't exceed
maximum allowable graph width (i.e. GRAPH_length_max).

2) Next, apply that to the graphed 'Mem' portion which
is likely to remain entirely visible. However, it will
grow or shrink depending on total adjacent cpu graphs.

3) Last, the same width is used for the 'Swap' portion
but that graph is considered sacrificial and very well
could be truncated depending on the width of a screen.

[ along the way, when the cpu graphs revert to their ]
[ abbreviated form, the memory graphs will also show ]
[ an abbreviated prefix. in this way the widths will ]
[ also be maximized, reducing potential distortions. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
bf916fdf04 top: cosmetic changes with two abreast summary display
This commit will change some comments, adjust a little
whitespace but mostly rename some #define identifiers.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
96153c0f0c top: distinct separator if two abreast summary display
When displaying detailed memory statistics two abreast
data for the lines are less than those for cpus. So we
can exploit such a difference to provide a distinctive
separator. This may help separating cpu & memory data.

[ in truth, this happened before this patch. what we ]
[ are doing now is polishing that accidental feature ]
[ and placing it under the control of a conditional. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
e5386f1f21 top: harden detailed stats two abreast summary display
When displaying detailed cpu statistics, as opposed to
those scalable graphs, only two per line can be shown.

Therefore, if we are showing a detail version, our '4'
toggle must prematurely revert to single mode display.

Conversely, the 't' toggle must also turn off that '4'
toggle rather than try to print more than 2 abreast if
we're currently executing in detailed statistics mode.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
5c5bff392b top: refined memory graphs two abreast summary display
When more than two cpus are displayed per summary area
line in graph form, those memory graphs were scaled to
that same width for consistency & aesthetics. However,
they probably shouldn't have been reduced to less than
terminal width due to a resulting loss of information.

[ after all, detailed memory stats are never reduced ]

So now, supporting logic was refactored to behave just
as it did before the 4 toggle was expanded beyond '1'.

[ the changes impact the 2 memory graphs exclusively ]

Reference(s):
https://www.freelists.org/post/procps/top-enhancements-2-bugs-swatted,1

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-13 19:55:17 +10:00