You are not logged in.
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.
bing different
Offline
Well, as per seth advice I have added an udev rule regarding usb autosuspend and the disk began going autosleep. Though those "freezable" threads keep exist, they are seemingly don't disturb storage devices. So I mark this thread solved.
bing different
Offline
Confirmed. This is like chasing ghosts. Although the HD-LED of the PC hardware clone behaves differently, I cannot figure out any further substantial differences between ubuntu on this or on the other PC or between various arch kernels.
For me, the mystery remains, but I will get used to it.
Offline
Sorry for bringing this up again. This constant idle disk writing (a SSD killer btw) is caused by the "workqueue power-efficient mode" power management option. The kernel config flag is WQ_POWER_EFFICIENT_DEFAULT and should be off by default. There is a good reason this is off in the kernel defconfig.
Offline
You should raise this here: https://bugs.archlinux.org/?project=1&string=linux and ideally elaborate on the "good reason" to convince the kernel maintainer. (eg. a link to a discussion etc.)
Offline
@akiko Thanks for pointing in the right direction for solving this puzzle. Internet search tells that this feature is enabled in the default kernel config and arch developers maybe just follow the upstream. Though this proactive energy saving seems to be useful only for notebooks and totally unneeded in desktops.
Last edited by nbd (2018-12-10 00:29:16)
bing different
Offline
@nbd did adding the boot option workqueue.power_efficient=0 resolve the issue on your system?
https://git.kernel.org/pub/scm/linux/ke … 4d3fabc7aa is the commit introducing power efficient work queues
From kernel/power/Kconfig
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?
Offline
@loqs
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.
bing different
Offline
You can check the value the kernel is using with
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.
Offline
Booting with workqueue.power_efficient doesn't seem to change much:
[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.
bing different
Offline
I have been suffering the same issue using since... 4.20 maybe?
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.
Offline