#1211 has shown reading /proc/<pid>/status might have a significant
performance impact. It was started to be read by default to gather the
permitted capabilities of the process.
Gather permitted capabilities via the syscall capget(2) instead.
cap_get_proc(3) is not used to avoid linking with -lcap.
Kernel threads are commonly not based on an executable and their cmdline
therefore just a human readable string.
On Linux this string might contain slashes, e.g. kworker/7:5H-ttm, which
cause Process_writeCommand() to print only the trailing parts if the
option *Show Program Path* is disabled.
Reported-and-Suggested-By: mmrmaximuzz
Fixes: #1391
While abstracting processes from row display, code relating to
row parent sorting was moved to row-level that in fact must be
done at process-level (using the Row_compareByParent_Base call
circumvented this unintentially).
Resolves#1378
Set the process user ID to an invalid value of -1 to trigger a name
lookup for IDs with the value 0 ("root"). This initialization was
dropped in commit 0f751e99 ("Introduce Row and Table classes for screens
beyond top-processes").
Fixes: 0f751e99 ("Introduce Row and Table classes for screens beyond top-processes")
Following up with some discusson from a few months back,
where it was proposed that ProcessTable is a better name.
This data structure is definitely not a list ... if it
was one-dimensional it'd be a set, but in practice it has
much more in common with a two-dimensional table.
The Process table is a familiar operating system concept
for many people too so it resonates a little in that way
as well.
This implements our concept of 'dynamic screens' in htop, with a
first use-case of pcp-htop displaying things like top-filesystem
and top-cgroups under new screen tabs. However the idea is more
general than use in pcp-htop and we've paved the way here for us
to collectively build mroe general tabular screens in core htop,
as well.
From the pcp-htop side of things, dynamic screens are configured
using text-based configuration files that define the mapping for
PCP metrics to columns (and metric instances to rows). Metrics
are defined either directly (via metric names) or indirectly via
PCP derived metric specifications. Value scaling and the units
displayed is automatic based on PCP metric units and data types.
This commit represents a collaborative effort of several months,
primarily between myself, Nathan and BenBE.
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Signed-off-by: Nathan Scott <nathans@redhat.com>
This commit refactors the Process and ProcessList structures such
they each have a new parent - Row and Table, respectively. These
new classes handle screen updates relating to anything that could
be represented in tabular format, e.g. cgroups, filesystems, etc,
without us having to reimplement the display logic repeatedly for
each new entity.
The SPACESHIP_NUMBER() macro does not work well with floating point
values that are possible to be NaNs. Change the compare logic of all
percentage fields of Process entries to use compareRealNumbers().
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
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>
In PCPProcess_writeField(), the "n" variable should be size_t type.
The "n" parameters of Process_printPercentage() and
PCPProcess_printDelay() should be size_t type as well.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
htop was liable to display erroneous sizes. For instance, a program
consuming 85.00 TiB (93.46 TB) of virtual memory used to be reported as
consuming "87.0T".
First stage in sanitizing the process list structure so that htop
can support other types of lists too (cgroups, filesystems, ...),
in the not-too-distant future.
This introduces struct Machine for system-wide information while
keeping process-list information in ProcessList (now much less).
Next step is to propogate this separation into each platform, to
match these core changes.
Highlight processes started from binaries with file capabilities set,
like kwin_wayland, or retaining Linux capabilities, via the ambient set,
after switching from the root user, e.g. rtkit.
Add a process column for scheduling policy to show the current
scheduling policy of the process.
Add a the ability to change the scheduling policy of a process via the
key 'Y'.
Currently implemented on Linux and FreeBSD only but should be portable,
since sched_getscheduler(2) is part of POSIX.1-2001.
Closes: #1161
This includes:
- Wrap function implementations
- Pointer alignment for function signatures
- Pointer alignment for variable declarations
- Whitespace after keywords
- Whitespace after comma
- Whitespace around initializers
- Whitespace around operators
- Code indentation
- Line break for single line statements
- Misleading alignment
CRT.c:1015:14: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void CRT_done() {
^
void
Also increase the limit for nesting by using 64 bit integers.
ProcessList.c:242:36: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
#0 0x561cfec000a8 in ProcessList_buildTreeBranch ProcessList.c:242:36
#1 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#2 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#3 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#4 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#5 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#6 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#7 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#8 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#9 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#10 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#11 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#12 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#13 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#14 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#15 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#16 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#17 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#18 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#19 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#20 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#21 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#22 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#23 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#24 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#25 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#26 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#27 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#28 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#29 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#30 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#31 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#32 0x561cfebfb734 in ProcessList_buildTree ProcessList.c:312:10
#33 0x561cfebfb050 in ProcessList_updateDisplayList ProcessList.c:326:10
#34 0x561cfebfc58b in ProcessList_rebuildPanel ProcessList.c:374:4
#35 0x561cfec07953 in checkRecalculation ScreenManager.c:139:7
#36 0x561cfec07953 in ScreenManager_run ScreenManager.c:226:10
#37 0x561cfeb8899a in CommandLine_run CommandLine.c:378:4
#38 0x561cfeb6d6d4 in main htop.c:15:11
#39 0x7f14860291e9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#40 0x7f148602929b in __libc_start_main csu/../csu/libc-start.c:392:3
#41 0x561cfeaafb20 in _start (htop+0x105b20) (BuildId: fc4b9e52ffc111ca8b4cd53136a238414120a858)
Since commit edf319e[1], we're dynamically adjusting column width of
"CPU%", showing single digit precision also for values greater than
"99.9%" makes "CPU%" column consistent with all other values.
[1]: edf319e53d
Change "Process_printPercentage()" function's logic to always display
value (i.e. "val") with single precision. Except when value is greater
than "99.9%" for columns like "MEM%", whose width is fixed to "4" and
value cannot go beyond "100%".
Credits: @Explorer09, thanks for the patch[2] to fix title alignment
issue.
[2]: https://github.com/htop-dev/htop/pull/959#issuecomment-1092480951Closes: #957
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.
Christian Göttsche
Explorer09
Nathan Scott
Benny Baumann
Sohaib Mohamed
Xavier G
arza
Stefan
Kumar
Charlie Vieth
Jan Kończak
Hisham Muhammad
marcluque
Silke Hofstra
Daniel Lange
Nathan Scott