If you transferred this many documents, it is possible that indexing is still running on these. It will take time to get an initial index done for a huge number of docs.
On last check the indexing was at 100%, although the index file seems to be written to constantly, based on the warnings that borg backup keeps giving me: Warning: FileChangedWarning – /home/gregory/.local/share/baloo/index: file changed while we backed it up.
Hmmm, perhaps a bit? It’s not entirely clear. I’ve calibrated powertop and run its auto-tune command, per @cactux, and I’ve disabled file indexing with balooctl6 disable, per @dalto. Here’s what I’m seeing now:
PowerTOP 2.16-rc3 Overview Idle stats Frequency stats Device stats Tunables WakeUp
▒
The battery reports a discharge rate of 20.4 W ▒
The energy consumed was 410 J ▒
The estimated remaining time is 1 hours, 5 minutes ▒
▒
Summary: 1789.9 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 24.1% CPU use ▒
▒
Usage Events/s Category Description ▒
7.1 pkts/s Device Network interface: wlan0 (iwlwifi) ▒
12.8 ms/s 944.7 Timer tick_nohz_handler ▒
0.9 ms/s 172.6 Process [PID 21937] /usr/bin/nvidia-smi dmon -d 2 -s pucm ▒
22.9 ms/s 158.8 Interrupt [7] sched(softirq) ▒
2.1 ms/s 98.9 Interrupt [40] idma64.2 ▒
9.0 ms/s 72.8 Timer hrtimer_wakeup ▒
20.7 ms/s 54.7 Process [PID 20693] /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_CdjKtn --xwayla▒
35.6 ms/s 37.6 Process [PID 25783] /usr/lib/firefox/firefox ▒
1.2 ms/s 37.3 Process [PID 25840] /usr/lib/firefox/firefox ▒
271.8 µs/s 22.8 Timer i915_sample [i915] │
49.2 µs/s 21.3 kWork intel_atomic_commit_work [i915] │
1.3 ms/s 21.1 Interrupt [142] i915 │
651.2 µs/s 21.1 kWork intel_atomic_cleanup_work [i915] │
35.0% Device Display backlight │
0.9 ms/s 19.6 Process [PID 26364] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:48997 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
10.8 ms/s 15.6 Process [PID 26272] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:48890 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
1.6 ms/s 6.7 Process [PID 509] [irq/180-VEN_04F] │
51.5 ms/s 6.5 Process [PID 26346] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:48997 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
6.4 ms/s 6.1 Process [PID 20846] /usr/bin/plasmashell --no-respawn │
13.4 µs/s 3.7 kWork toggle_allocation_gate │
30.0 µs/s 3.5 Process [PID 107] [ksoftirqd/1] │
11.4 µs/s 3.3 kWork console_callback │
424.8 µs/s 3.2 kWork __i915_gem_free_work [i915] │
33.1 µs/s 3.2 Process [PID 866] [irq/204-iwlwifi] │
83.4 µs/s 2.7 Process [PID 21569] /opt/1Password/1Password-Crash-Handler │
108.1 µs/s 2.3 Process [PID 16] [rcu_preempt] │
25.4 µs/s 2.3 kWork ct_incoming_request_worker_func [i915] │
248.8 µs/s 2.3 Interrupt [3] net_rx(softirq) │
1.3 ms/s 2.1 Process [PID 20914] /usr/bin/ksystemstats │
16.4 µs/s 2.0 Timer dl_task_timer │
170.3 µs/s 1.8 kWork kcryptd_crypt [dm_crypt] │
12.6 µs/s 1.6 Process [PID 878] [irq/216-iwlwifi] │
111.0 µs/s 1.6 kWork psi_avgs_work │
77.4 µs/s 1.6 Process [PID 26571] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:49054 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
53.9 µs/s 1.4 kWork handle_update │
299.4 µs/s 1.3 Process [PID 156] [irq/9-acpi] │
2.9 ms/s 1.3 Process [PID 26182] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:58606 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
1.2 ms/s 1.2 Process [PID 21256] /usr/bin/konsole │
110.2 µs/s 1.2 Process [PID 26767] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:49054 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
4.2 ms/s 1.1 Process [PID 25794] /usr/lib/firefox/firefox │
6.5 µs/s 1.1 kWork __delay_sched_disable [i915] │
287.2 µs/s 1.1 Process [PID 943] /usr/bin/NetworkManager --no-daemon │
44.8 µs/s 1.0 Process [PID 25943] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:46852 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
513.9 µs/s 0.9 kWork btrfs_work_helper │
299.7 µs/s 0.9 Process [PID 27155] powertop │
66.4 µs/s 0.9 kWork iwl_mvm_tcm_work [iwlmvm] │
30.7 µs/s 0.9 Process [PID 26765] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:49054 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
28.4 µs/s 0.9 Process [PID 20962] /usr/lib/org_kde_powerdevil │
3.3 µs/s 0.9 kWork clone_write_end_io_work │
116.0 µs/s 0.9 kWork delayed_fput │
46.9 µs/s 0.9 kWork engine_retire [i915] │
32.9 ms/s 0.7 Interrupt [14] INTC1055:00 │
31.7 µs/s 0.7 Process [PID 26990] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:49054 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
41.4 µs/s 0.6 kWork iwl_mvm_async_handlers_wk [iwlmvm] │
26.7 µs/s 0.6 Process [PID 15] [ksoftirqd/0] │
14.7 µs/s 0.6 Process [PID 26196] /usr/lib/firefox/firefox -contentproc -isForBrowser -prefsHandle 0:58606 -prefMapHandle 1:289678 -jsInitHandle 2:156120 -parentBuildID 20260525202655 -sandboxReporter 3│
1.9 ms/s 0.6 Process [PID 25804] /usr/lib/firefox/firefox │
55.6 µs/s 0.5 Process [PID 21935] /usr/lib/ksystemstats_intel_helper 0000:00:02.0 │
<ESC> Exit | <TAB> / <Shift + TAB> Navigate |
I’ve run those extra commands you’ve suggested, although I’m not sure what to make of them. I noticed that the runtime_usage wasn’t there, but I found something called runtime_active_time.
[gregory@gregory-xps159530 ~]$ lspci -nnk -s 01:00.0
0000:01:00.0 3D controller [0302]: NVIDIA Corporation AD107M [GeForce RTX 4050 Max-Q / Mobile] [10de:28a1] (rev a1)
Subsystem: Dell Device [1028:0beb]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
active
[gregory@gregory-xps159530 ~]$ lspci -nnk -s 01:00.0
0000:01:00.0 3D controller [0302]: NVIDIA Corporation AD107M [GeForce RTX 4050 Max-Q / Mobile] [10de:28a1] (rev a1)
Subsystem: Dell Device [1028:0beb]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time
131922
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_usage
cat: '/sys/bus/pci/devices/0000:01:00.0/power/runtime_usage': No such file or directory
[gregory@gregory-xps159530 ~]$ sudo ls /sys/bus/pci/devices/0000:01:00.0/power/
Place your finger on the fingerprint reader
autosuspend_delay_ms runtime_active_time runtime_suspended_time wakeup_abort_count wakeup_active_count wakeup_expire_count wakeup_max_time_ms
control runtime_status wakeup wakeup_active wakeup_count wakeup_last_time_ms wakeup_total_time_ms
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time
7516512
PS If you will forgive one more bump, I also wonder if I should have enabled swap already?
runtime_suspended_time = 131922 is the total time ( in miliseconds, I believe) that GPU has spent in runtime suspend.
runtime_active_time = 7516512 is the total time the GPU has been active.
It looks like power management is available but something keeps waking your dGPU up if it should be idle.
Did you try nvtop that was suggested in that section of The Wiki you linked to?
There are those who will tell you that they have XXL GB of ram and they have never had any issues. They are wrong, if I may put it bluntly.
Your kernel will thank you with some amount of swap, be it only ram-based like zram or the combo of zswap (a kernel feature already enabled) + a device-backed swap space (file or partition). The ArchWiki covers both options.
This is an excellent article about swap which explains why you should be using it:
Personally, I have opted for zswap plus swapafile mainly because it is a kerne feature already enabled and integrated in kernel’s memory management.
Here is another equally excellent article ( by the same author) about zswap and zram and why most users will do just fine with the former unless they have a compelling use case to choose the latter:
I must have missed that thing about nvtop. Thank you!
As for swap, I was hoping I would get to put that off until after I resolved the power issue so that I wouldn’t throw off the results of my power monitoring my altering too many variables at once. I was thinking of just using zram as that’s what was set up automatically when I was using Fedora, but honestly I might as well use a swap subvolume in btrfs, seeing as subvolumes are so easy to add. I guess I’ll start by checking the “In Defense of Swap” I’ve had open for a couple of days. 
I will get back to you all when I’ve tried those two things.
Hey there, @cactux. I’ve finally enabled swap in addition to looking at nvtop and looking into nvidia-related processes.
I didn’t see any Nvidia GPU processes in nvtop, but interestingly I did see a little Nvidia VRAM use (screenshot below). I did look into why /usr/bin/nvidia-smi dmon -d 2 -s pucm is running, and it appears that it’s a child process of /usr/bin/ksystemstats, which is in turn a child of 0:00 /usr/lib/systemd/systemd --user.
The Wiki’s NVIDIA Optimus page has a troubleshooting section on situations where the NVIDIA GPU will not turn off or stay off, and it mentions thermal monitors spawning nvidia-smi:
If you use a thermal monitor that is probing your GPU temperature, it typically calls
nvidia-smito get this temperature, which will wake up your GPU and keep it in an active state.
I’m amused and annoyed by the possibility that monitoring tools are actually contributing to this problem. I have powertop, glances, and nvtop open right now.
nvtop screenshot:
PS: It’s probably redundant to have both switcheroo-control and envycontrol installed at this point, right?
Frustratingly enough, it seems that I can bring my wattage back down to ~7-8W by masking plasma-ksystemstats.service on the user level like so: systemctl --user mask plasma-ksystemstats.service. I’m not sure whether or not that’s considered safe or not. I mean, that’s a user-level service, so I would hope that the kernel would still be able to get temperature data for the sake of the governor or something? I imagine there is a better way of doing this somehow.
I have also been suspecting that these monitoring tools could contribute to the issue and keep dGPU from enetring runtime suspend even then it is apparently not in use.
From what I’ve gathered any monitoring tools that read GPU sensors can prevent runtime suspend.
As a test, I would suggest to stop/disable any monitoring tool including any plasma widget/applet/app etc. that can read the sensors and let the system to be idle for a while. Then I would check with the commands:
$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time
$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_usage
Hopefully, the runtime_status will show: suspend (or something to that effect).
PS. By the way, post some system spec like: inxi -a -z -SMCG and cat /proc/cmdline for people to have some “context”.
Since I’ve masked the monitor user service that I mention in my previous post, my dGPU usage has been much better. Now if only there were a less hacky approach here. Here’s what I got from your the “cat /sys/…” commands you shared:
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
suspended
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time
2960425
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_usage
cat: '/sys/bus/pci/devices/0000:01:00.0/power/runtime_usage': No such file or directory
[gregory@gregory-xps159530 ~]$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time
281061
Here are the system spec outputs you requested:
inxi -a -z -SMCG: https://dpaste.com/5WT6BKENScat /proc/cmdline: https://dpaste.com/992Z7QVMP
Thanks for all your help!
This looks good! That’s exactly what you would want to see when the dGPU is idle.
These are also much better figures than your previous results. The time the device spends in runtime suspend is more than ten times it is active.
So stopping and disabling all the monitoring tools and services seems to have produced a beneficial result.
The service you have masked is delivered by the package ksystemstats which is in turn a required dependency of plasma-systemmonitor, etc. It seems to be bundled in Plasma in a way that you cannot simply remove it without breaking your DE.
[/rant]
This is the bliss and curse of all these big DEs which wants to be universal and everything to everyone. They would pack in stuff that some users may not want or use and deliver all sorts of utensils and kitchen appliances.
[rant/]
From what I’ve found, ksystemstats process loads a set of plugins that collect metrics from Linux interfaces such as /proc, /sys, lm-sensors, network statistics, disk statistics, pressure stall information, and other kernel-provided data sources. The collected metrics are then exposed through D-Bus so Plasma components can query them efficiently
So if you don’t need all the monitoring applets, widgets, apps and what-nots, masking the service should not have any detrimental effect on how your DE will work specifically and your OS generally.
Or perhaps just stop using the mentioned monitoring “appliances” would amount to the same result.
Thank you for your assurances. I removed the monitoring desktop widgets and unmasked ksystemstats. Now I’m finding that the dGPU’s runtime status switches to active when I have the KDE System Monitor open and switches back to suspended seconds after I close the monitor.
I noticed that Arch did a new release of ksystemstats, but they don’t seem to provide a changelog, and I noticed that the commit log just says something about detecting capabilities of some sort in fakeroot builds: Rebuild with fakeroot 1.37 to fix capabilities. As such, it’s hard for me to know what they did that for.
Thanks again, everyone!
pkgver=6.6.5
pkgrel=2
Judging by this, it doesn’t seem to be a version bump to that package but a rebuild to fix some issues regarding setting capabilities for /usr/lib/ksystemstats_intel_helper?
package() {
DESTDIR="$pkgdir" cmake --install build
setcap CAP_PERFMON=+ep "$pkgdir"/usr/lib/ksystemstats_intel_helper
}
It looks like that the commit you linked is fixing packaging so the installed binary actually retains the required capability.
Though I have to admit that much of the package building intricacies go above my head so perhaps other users might be able to provide a much more detailed and accurate analysis.
That goes over my head too, as I know nothing about the capabilities model. Regardless, eliminating unnecessary monitor widgets solved my problem, as described above.