htop is using much cpu itself

[webcaptcha]

I'm on KDE Plasma on Wayland session

Terminal emulator - Alacritty
When I run htop it's usually shows around 15% CPU with peaks up to 25%

Is it ok? For example on the screenshot at the same time Firefox was playing video.

If it needed I can make a video but almost all time it uses than numbers of CPU

CPU - AMD 7840HS
GPU - intergrated
RAM - 32GB

htop default config

[Explorer09]

The CPU percentage displayed is per core, so when you have 16 CPU core (or threads) active, the maximum would be 1600%.
Do you consider this takes too much CPU usage?

[natoscott]

@webcaptcha are you using the default sampling interval (1.5s) or something more frequent?
Looks like you have over 2000 processes running there - visiting each in /proc does take a small amount of time and it all adds up. You might find some additional insights by adding the UTIME and STIME columns and observing htop there as well (I expect you'll see much higher kernel time than user time).

[BenBE]

Can you provide a copy of your htoprc configuration file?

[ivanstepanovftw]

Same for me on Fedora and Debian. Even though I have 8C/16T, laptop at the summer just burns your knees, so you have to monitor what to close, and htop just shouldn't be running in the background. Not critical, but others do not experience high CPU usage by htop itself. I also did not find any relevant bug reports except this one.

My thoughts at first was that this high CPU usage is just at this exact point of the time when it refreshes info, but top shows exactly the same with independent refresh rate.

Here is mine ~/.config/htop/htoprc, I hope it helps.

Details

# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
htop_version=3.2.2
config_reader_min_version=3
fields=0 48 17 18 38 39 40 2 46 47 49 1
hide_kernel_threads=1
hide_userland_threads=1
hide_running_in_container=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_deleted_exe=1
shadow_distribution_path_prefix=0
highlight_megabytes=1
highlight_threads=1
highlight_changes=0
highlight_changes_delay_secs=5
find_comm_in_cmdline=1
strip_exe_from_cmdline=1
show_merged_command=0
header_margin=1
screen_tabs=1
detailed_cpu_time=0
cpu_count_from_one=0
show_cpu_usage=1
show_cpu_frequency=1
show_cpu_temperature=1
degree_fahrenheit=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
enable_mouse=1
delay=15
hide_function_bar=0
header_layout=two_50_50
column_meters_0=LeftCPUs2 Memory Swap
column_meter_modes_0=1 1 1
column_meters_1=RightCPUs2 Tasks LoadAverage Uptime
column_meter_modes_1=1 2 2 2
tree_view=0
sort_key=46
tree_sort_key=0
sort_direction=-1
tree_sort_direction=1
tree_view_always_by_pid=0
all_branches_collapsed=0
screen:Main=PID USER PRIORITY NICE M_VIRT M_RESIDENT M_SHARE STATE PERCENT_CPU PERCENT_MEM TIME Command
.sort_key=PERCENT_CPU
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0
screen:I/O=PID USER IO_PRIORITY IO_RATE IO_READ_RATE IO_WRITE_RATE PERCENT_SWAP_DELAY PERCENT_IO_DELAY Command
.sort_key=IO_RATE
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0

I did not changed default refresh rate, I have only added sensors info, CPU frequency, majfaults and "hide userland process threads" or something like that.

[ivanstepanovftw]

Forgot to mention, my CPU is AMD too: AMD Ryzen 7 5800U. I don't remember that I had this issue with Intel before.

[cgzones]

Could you try to disable CPU frequency or CPU temperature and check whether the behavior persists.

[ivanstepanovftw]

Tried to disable both CPU frequency and CPU temperature and restarting htop, CPU usage is the same before and after, behavior persisted.

Details

[ivanstepanovftw]

This fixes high load:

Subject: [PATCH] Commented function
---
Index: linux/LinuxProcessTable.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/linux/LinuxProcessTable.c b/linux/LinuxProcessTable.c
--- a/linux/LinuxProcessTable.c	(revision fc54b885ef75b8edacc4a9758f29b51e16025d34)
+++ b/linux/LinuxProcessTable.c	(date 1725503862876)
@@ -629,6 +629,7 @@
  * Read /proc/<pid>/maps (process-shared data)
  */
 static void LinuxProcessTable_readMaps(LinuxProcess* process, openat_arg_t procFd, const LinuxMachine* host, bool calcSize, bool checkDeletedLib) {
+   return;
    Process* proc = (Process*)process;
 
    proc->usesDeletedLib = false;

[ivanstepanovftw]

Before fix

Maybe changing buffer size will help, but I do not care. So htop relays on procfs? But why it even reads /maps?

[BenBE]

There are two reasons for reading /proc/<pid>/maps:

1. Library Sizes (size of shared libraries used by the process), which is not provided by the kernel since ancient times
2. Process up-to-date marking (highlighting processes where binaries like libraries have been replaced, e.g. by an update)

The problem with these is BTW not the routine itself, but that the kernel is slow in providing these information. The parsing of these lines is already heavily optimized to avoid slow libc functions where ever possible.

[ivanstepanovftw]

Nice useful features! Can I disable them?

[BenBE]

Yes.

1. Library Size accounting is automatically disabled, when the corresponding column is not shown
2. Up-to-date marking can be configured on the setup screen under Display Options using the checkbox labelled "Highlight out-dated/removed programs (red) / libraries (yellow)"

[ivanstepanovftw]

Unchecking "Highlight out-dated/removed programs (red) / libraries (yellow)" is the solution of this issue for me!