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 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.
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.
This removes the duplication of dynamic meter/column hashtable
pointers that has come in between the Settings and ProcessList
structures - only one copy of these is needed. With the future
planned dynamic screens feature adding another pointer, let us
first clean this up before any further duplication happens.
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)
As the loop checks `tree_depth`, a tree build is needed to ensure
they're filled in correctly. Note that this breaks the display list sort
order in case it's non-tree-based (either startup in flat mode, or `*`
hotkey in flat mode), so the display list will need to be sorted again.
* The size of titleBuffer should be 257 bytes, not 256.
* Remove redundant `static char titleBuffer[]` delarations within
`alignedProcessFieldTitle()` and let the subroutine use one shared
buffer for printing field title. This reduces code size.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
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
As the "highlight dying processes" option has to keep processes in the
list when they disappear, no code except the cleanup loop in
`ProcessList_scan` should remove processes from the list directly.
Remove the export to prevent random process removals from being
reintroduced accidentally.
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.
This enables:
* Multiple filters in the main panel and strace etc. views
* Multiple search terms
The search terms are separated by "|" and are still fixed strings
matched case-insensitive.
Added a multi flag at request of BenBE.
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.
ProcessList_buildTree does not need any particular sort order for
children of the same process or roots. Switching these to the sort order
configured by the user produces sorted tree automatically, making repeat
sort unnecessary.
ProcessList_buildTreeBranch used to search for children with a linear
scan of the process table, which made tree build time quadratic in
process count. Pre-sorting the list by parent PID (if known) makes it
possible to select the correct slice by bisection much faster.
Separate `processes` (the vector owning the processes, sorted in
whatever order is needed right now internally) and `displayList` (a
vector referencing the processes in the same order they're to be
displayed).
Special-casing hidden processes does not serve any obvious purpose and
depends on the move from processes to processes2 which will be removed
in a later commit.
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.
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
This commit is based on exploratory work by Sohaib Mohamed.
The end goal is two-fold - to support addition of Meters we
build via configuration files for both the PCP platform and
for scripts ( https://github.com/htop-dev/htop/issues/526 )
Here, we focus on generic code and the PCP support. A new
class DynamicMeter is introduced - it uses the special case
'param' field handling that previously was used only by the
CPUMeter, such that every runtime-configured Meter is given
a unique identifier. Unlike with the CPUMeter this is used
internally only. When reading/writing to htoprc instead of
CPU(N) - where N is an integer param (CPU number) - we use
the string name for each meter. For example, if we have a
configuration for a DynamicMeter for some Redis metrics, we
might read and write "Dynamic(redis)". This identifier is
subsequently matched (back) up to the configuration file so
we're able to re-create arbitrary user configurations.
The PCP platform configuration file format is fairly simple.
We expand configs from several directories, including the
users homedir alongside htoprc (below htop/meters/) and also
/etc/pcp/htop/meters. The format will be described via a
new pcp-htop(5) man page, but its basically ini-style and
each Meter has one or more metric expressions associated, as
well as specifications for labels, color and so on via a dot
separated notation for individual metrics within the Meter.
A few initial sample configuration files are provided below
./pcp/meters that give the general idea. The PCP "derived"
metric specification - see pmRegisterDerived(3) - is used
as the syntax for specifying metrics in PCP DynamicMeters.
Refactor the sample time code to make one call to gettimeofday
(aka the realtime clock in clock_gettime, when available) and
one to the monotonic clock. Stores each in more appropriately
named ProcessList fields for ready access when needed. Every
platform gets the opportunity to provide their own clock code,
and the existing Mac OS X specific code is moved below darwin
instead of in Compat.
A couple of leftover time(2) calls are converted to use these
ProcessList fields as well, instead of yet again sampling the
system clock.
Related to https://github.com/htop-dev/htop/pull/574
Currently the tree-view is empty on OpenBSD when kernel threads are
hidden, cause the kernel thread 'swapper' has pid 0 and gets treated as
root of the tree and parent of 'init'.
Do not build any tree with a pid 0 root node.
The local stack buffer does not need to be cleaned to zeros when
- just initialized, cause the length is set to 0 and the first
character is set to '\0', so all printing functions will safely stop
- no further used, i.e. the variable goes out of scope
- stay in follow mode on sort inversion (I)
- stay in follow mode after viewing help screen (h)
- select parent process (where available) when having followed a thread
and hiding these (H)
Closes: #560
If the last process entry is selected and the process dies, stay at the
end of the list and do not jump to the start.
Also if the last entry is selected keep, after rebuilding the process
list due to a new scan, the last entry selected.
Benny Baumann
Nathan Scott
gandalf3
Christian Göttsche
Denis Lisov
Explorer09
Kumar
Charlie Vieth
Daniel Lange
Hisham Muhammad
Silke Hofstra
Sohaib Mohamed
mayurdahibhate