Shared memory is not available for reclaim, and plays an equally
significant role in memory load as the "used" memory
Since "shared" was separated from the "used" value, the basic
"used/total" display in the bar text has become less meaningful
for Linux, as it only reflects a subset of the claimed memory.
The difference often isn't huge, but it can become so if tmpfs,
shmget()/shm_open() or MAP_SHARED is heavily used.
Improve the situation by adding shared memory to the "used" value in
the memory bar text.
[Reworded commit message and dropped "claimed" terminology as it is
completely non-standard and does not match the output of free(1).]
Shared memory is less available than buffers, so move it
left next to used memory.
This is in preparation for including shared memory in the
basic "in use" for the bar text. It would not make sense
to sum a discontiguous region.
The standard isnan() function is defined to never throw FP exceptions
even when the argument is a "signaling" NaN. This makes isnan() more
expensive than (x != x) expression unless the compiler flag
'-fno-signaling-nans' is given.
Introduce functions isNaN(), isNonnegative(), isPositive(),
sumPositiveValues() and compareRealNumbers(), and replace isnan() in
htop's codebase with the new functions. These functions utilize
isgreater() and isgreaterequal() comparisons, which do not throw FP
exceptions on "quiet" NaNs, which htop uses extensively.
With isnan() removed, there is no need to suppress the warning
'-Wno-c11-extensions' in FreeBSD. Remove the code from 'configure.ac'.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
For now, the semantics are mostly fit for Linux zswap subsystem. For
instance, we add the third swap usage metric that indicates the amount
of memory that is accounted to swap but in fact stored elsewhere. This
exactly matches the definition of frontswap/zswap, and is probably of
little use to all other platforms.
Use similar calculation than procps.
Show AvailableMemory in text mode.
Use total minus available memory instead of manually computed used-
memory as fraction part in bar mode (if available).
RichString_writeFrom takes a top spot during performance analysis due to the
calls to mbstowcs() and iswprint().
Most of the time we know in advance that we are only going to print regular
ASCII characters.
Reasoning:
- implementation was unsound -- broke down when I added a fairly
basic macro definition expanding to a struct initializer in a *.c
file.
- made it way too easy (e.g. via otherwise totally innocuous git
commands) to end up with timestamps such that it always ran
MakeHeader.py but never used its output, leading to overbuild noise
when running what should be a null 'make'.
- but mostly: it's just an awkward way of dealing with C code.
Rationale (copied from htop issue #471):
The function name "setValues" is misleading. For most OOP (object-
oriented programming) contexts, setXXX functions mean they will change
some member variables of an object into something specified in
function arguments. But in the *Meter_setValues() case, the new values
are not from the arguments, but from a hard-coded source. The caller
is not supposed to change the values[] to anything it likes, but
rather to "update" the values from the source. Hence, updateValues is
a better name for this family of functions.
Fix subtree hiding
Fix reading of CPU values in hidden threads
Fix hiding of zombie processes as kernel threads
Remove "debug proc" code
Code cleanup in processElements
Benny Baumann
Kevin Bracey
Explorer09
Ivan Shapovalov
Guillaume Gomez
Nathan Scott
Daniel Lange
mayurdahibhate
Christian Göttsche
Zev Weiss
Daniel Flanagan
Christian Hesse
Tomasz Kramkowski
Hisham Muhammad