journal_async_commit mount option seems to mitigate excessive disk write access
https://wiki.archlinux.org/index.php/ext4
I have yet to try disabling journal altogether.
]]>[root ~]# cat /sys/module/workqueue/parameters/power_efficient
N
[root ~]# pidstat -dl 20
Linux 4.19.1-arch1-1-ARCH (localhost) 12/09/2018 _x86_64_ (1 CPU)
10:00:51 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:01:11 AM 0 17 0.00 0.00 0.00 1 kworker/0:1-ata_sff
10:01:11 AM 0 138 0.00 0.00 0.00 1 kworker/0:2-events_power_efficient
10:01:11 AM 0 250 0.00 0.00 0.00 2 kworker/0:5-events_freezable_power_
10:01:11 AM 0 769 0.00 0.00 0.00 1 kworker/0:0-events_freezable_power_
10:01:11 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:01:31 AM 0 17 0.00 0.00 0.00 2 kworker/0:1-events_freezable_power_
10:01:31 AM 0 739 0.00 0.20 0.00 0 pidstat -dl 20
10:01:31 AM 0 769 0.00 0.00 0.00 4 kworker/0:0-events_freezable_power_
10:01:31 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:01:51 AM 0 17 0.00 0.00 0.00 2 kworker/0:1-ata_sff
10:01:51 AM 0 769 0.00 0.00 0.00 3 kworker/0:0-events_freezable_power_
10:01:51 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:02:11 AM 0 17 0.00 0.00 0.00 2 kworker/0:1-ata_sff
10:02:11 AM 0 739 0.00 0.20 0.00 0 pidstat -dl 20
10:02:11 AM 0 769 0.00 0.00 0.00 4 kworker/0:0-mm_percpu_wq
10:02:11 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:02:31 AM 0 17 0.00 0.00 0.00 2 kworker/0:1-events_freezable_power_
10:02:31 AM 0 769 0.00 0.00 0.00 3 kworker/0:0-events_freezable_power_
10:02:31 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:02:51 AM 0 17 0.00 0.00 0.00 2 kworker/0:1-ata_sff
10:02:51 AM 0 739 0.00 0.20 0.00 0 pidstat -dl 20
10:02:51 AM 0 769 0.00 0.00 0.00 4 kworker/0:0-events_freezable_power_
The solution with udev rule worked in the sense that the external HDD began to autosleep, but it didn't cause worker threads to disappear. As I wrote, the problem was constantly spinning HDD, not worker threads themselves. They were just considered as a possible cause of constant spinning. But as they seem to not make an actual access to storage devices (they appear in pidstat even with HDD LED indicator turned off) - I marked this topic solved. I thanked akiko because they informed on what these threads exactly are. But I don't know whether they meant that those threads are known to wear SDDs/HDDs.
]]>cat /sys/module/workqueue/parameters/power_efficient
You would probably need to disable the udev rule suggested by seth if that already resolved the issue to test if workqueue.power_efficient=0 also resolves the issue.
]]>At a quick glance I just misinterpreted the phrase: "Enable workqueue power-efficient mode by default" assuming that the default value for this feature in "on".
Thanks for the advice about a boot parameter, I will try it and report the result.
]]>config WQ_POWER_EFFICIENT_DEFAULT
bool "Enable workqueue power-efficient mode by default"
depends on PM
default n
The default added was n and that value has not been changed since its introduction as far as I can see. What is your source that the default upstream is enabled?
]]>I get the same behaviour and results booting with the archlinux live cd (2018.11).
Using kernel
[root@amd64-archlinux bernd_b]# uname -r 4.17.14-arch1-1-ARCH
at least the naming seems to change.
This (different thread names) can be due to more earlier kernel. Seems like experimenting with adding new untested features.
]]>Using kernel
[root@amd64-archlinux bernd_b]# uname -r
4.17.14-arch1-1-ARCH
at least the naming seems to change.
[root@amd64-archlinux bernd_b]# iotop -o -b -d 10
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
Total DISK READ : 0.00 B/s | Total DISK WRITE : 408.58 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 17.16 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
251 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.06 % [kworker/u32:7]
252 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.06 % [kworker/u32:8]
I have two new pcs with exact(!) the same hardware.
One is running with ubuntu, the other is an archlinux system.
I think that the way to the solution is to find out what kernel feature creates those "freezable_power" threads and then compare the kernel compile configuration parameters enabling that feature in Ubuntu and ArchLinux kernels. There are many search hits with "events_freezable_power_", but I could not find any which explains what those threads are (all those hits are just copy-pastes of some data dumps ).
]]>I tried kernel 4.19.2, 4.19.1, 4.18.16 and 4.18.11, but it seems to make no difference. Nothing I am aware of seems to produce any load, but there remain these "events_freezable_power" threads writing to the hard disk.
[root@amd64-archlinux bernd_b]# iotop -o -b -d 10
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 17.56 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
249 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.04 % [kworker/u32:6-events_power_efficient]
250 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.03 % [kworker/u32:7-events_freezable_power_]
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
250 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.05 % [kworker/u32:7-events_freezable_power_]
249 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.05 % [kworker/u32:6-events_freezable_power_]
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 78.97 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
249 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.06 % [kworker/u32:6-events_freezable_power_]
250 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.06 % [kworker/u32:7-events_freezable_power_]
[ ~ ]$ sudo hdparm -Y /dev/sdf3
/dev/sdf3:
issuing sleep command
disk begins constantly flashing until aborting with Ctrl-C. Maybe the fact that the root partition is mounted on it plays some role.
Later I will try booting with ArchISO, as graysky advised, but now I was forced to return back to 4.10 kernel, since upgrading to 4.19 created yet some other issues.
]]>