This commit changes ProcessList_scan to lazily remove Processes by
index, which is known, instead of performing a brute-force search by
pid and immediately reclaiming the lost vector space via compaction.
Searching by pid is potentially quadratic in ProcessList_scan because
the process we are searching for is always at the back of the vector
(the scan starts from the back of the vector). Additionally, removal
via Vector_remove immediately reclaims space (by sliding elements
down).
With these changes process removal in ProcessList_scan is now linear.
Changes:
* ProcessList: add new ProcessList_removeIndex function to remove
by index
* Vector: add Vector_softRemove and Vector_compact functions to
support lazy removal/deletion of entries Vector_softRemove
Vector_compact
* Vector: replace Vector_count with Vector_countEquals since it only
used for consistency assertions.
If the max PID or UID value for a platform is exactly a power of ten
(10000, 100000, etc.) the column widths of PID and UID would be 1 char
less than the correct number of digits. This is caused by the wrong
rounding function (ceil(x)); change to the correct one (trunc(x) + 1).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
SELinux contexts can be quite long; adjust the column width dynamically
at each cycle to the longest value.
Also with the recent addition of multiple screens, over-long columns can
be moved into their own screen.
Depending upon default behavior of the compiler and floating-point
environment, compiler could round down the value between "99.9" and
"100.0" to "99.0", instead of rounding it to the nearest value, "100.0".
Note: The floating-point environment access and modification is only
meaningful when "#pragma STD FENV_ACCESS" is set to "ON"[1]. Otherwise
implementation is free to assume that floating-point control modes are
always the default. So it would be a good idea to address the rounding
ambiguity between "99.9" and "100.0" to become compiler agnostic.
[1]: https://en.cppreference.com/w/c/numeric/fenv
Credits: @Explorer09, thanks for the suggestion.
When we run a process which utilizes CPU between 100.0% and 999.9%, htop
shows an unnecessary decimal character at the end of the value. For
example, '100.x' and '247.x' become '100.' and '247.' respectively.
When CPU utilization is less than and equal to '99.9%', show the result
with single digit precision and if result is less than four characters,
pad it with the blank space. When CPU utilization is greater than
'99.9%', show only integral part of the result and if it's less than
four characters, pad it with the blank space.
Closes: #946
Formatting the merged command string is now implemented in an platform
independent way. Drop the Process member getCommandStr designed for
overrides of individual platforms.
Commit d8dfbbd3 ("Tidy up process state handling") did change the
highlighting of the UNINTERRUPTIBLE_WAIT state (D) from red to gray.
As this state might means the process probably still has work to do and
can hint at bottlenecks, revert this particular change.
Fixes: d8dfbbd3 ("Tidy up process state handling")
While most Unix-like systems use 16-bit user IDs,
Linux supports 32-bit UIDs since version 2.6.
UIDs above 65535 are used for UID namespacing of containers,
where a container has its own set of 16-bit user IDs.
Processes in such containers will have (much) larger UIDs than 65535.
Because the current format strings for `ST_UID` and `USER`
are `%5d` and `%9d` respectively, processes with such UIDs
lead to misaligned columns.
Dynamically scale the `ST_UID` column and increase the size of `USER`
to 10 characters (length of UINT32_MAX) to ensure that the user ID always fits.
Additionally: clean up how the titlebuffer size calculation and ensure
the PID column has a minimum size of 5.
Found by clang-tidy.
home/christian/Coding/workspaces/htop/Process.c:505:13: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
WRITE_HIGHLIGHT(0, strlen(procComm), commAttr, CMDLINE_HIGHLIGHT_FLAG_COMM);
^
/home/christian/Coding/workspaces/htop/Process.c:461:13: note: expanded from macro 'WRITE_HIGHLIGHT'
continue; \
^
Update merged command-line when started with "Show custom thread names"
disabled and enabling at runtime.
Also only consider showThreadNames when working on userland threads.
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
Currently htop does not support offline CPUs and hot-swapping, e.g. via
echo 0 > /sys/devices/system/cpu/cpu2/online
Split the current single cpuCount variable into activeCPUs and
existingCPUs.
Supersedes: #650
Related: #580
Shared libraries can be replaced by an upgrade, highlight processes
using deleted shared libraries.
Link with highlightDeletedExe setting, enabled by default.
Currently only checked on Linux.
Add process columns showing the elapsed time since the process was
started.
Similar to STARTTIME, but shows the time passed since the process start
instead of the fixed start time of the process.
Closes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782636
Charlie Vieth