View previous topic :: View next topic |
Author |
Message |
musv Advocate
Joined: 01 Dec 2002 Posts: 3366 Location: de
|
Posted: Tue Nov 29, 2016 8:50 pm Post subject: [solved] kworker runs on 30% |
|
|
Hi there,
I just noticed, that one kworker process runs constantly on 30% of cpu last.
top tells me:
Code: | PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
82 root 20 0 0 0 0 S 30,2 0,0 1:06.92 kworker/0:1 |
How can I find out, which kernel option is causing this problem?
I'm running kernel 4.8.10 and 4.8.7. Due to the re-usage of the kernel config, this problem occurs on both kernel versions.
/proc/config.gz
Last edited by musv on Wed Nov 30, 2016 1:49 pm; edited 1 time in total |
|
Back to top |
|
|
tholin Apprentice
Joined: 04 Oct 2008 Posts: 207
|
Posted: Wed Nov 30, 2016 11:13 am Post subject: |
|
|
My solution might not be the best but it works.
You can use kernel tracing to find out what that kworker is doing. Run "echo "workqueue:workqueue_queue_work" > /sys/kernel/debug/tracing/set_event" and then grep /sys/kernel/debug/tracing/trace for the pid of the kworker. In your example 82. This assumes that the debugfs is mounted and the kernel is compiled with support for tracing.
You should get a line like:
kworker/0:1-82 [000] d..2 5427.299626: workqueue_queue_work: work struct=ffff88033ad992d0 function=kcryptd_crypt workqueue=ffff88041bcd3400 req_cpu=8 cpu=4294967295
Here we see that on my system kworker/0:1 with pid 82 ran the kernel function "kcryptd_crypt". So we know that kworker/0:1 is doing work related to cryptography (dm-crypt).
Sometimes the function you get has a none descriptive name like "function=do_worker". Then you have to grep the kernel source to find out what that is.
drivers/md/dm-thin.c got the line INIT_WORK(&pool->worker, do_worker); and that is the only use of do_worker so the kworker calling do_worker is doing work related to dm-thin.
Once you found what kernel code is executed you have to manually check menuconfig for something that disables that code. |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3366 Location: de
|
Posted: Wed Nov 30, 2016 1:48 pm Post subject: |
|
|
Thanks, I'll keep this in my mind.
Until now there's no /sys/kernel/debug/tracing folder. I guess, I have to add some tracing support into the kernel config.
Nevertheless I found the error by brute force methode of recompiling the kernel again and again.
I have 2 soundcards in my computer - a Asus Xonar DS and an internal HDA Intel. I'm using the same sound card config already for about 4 years. The problem I notice since 4.8.7.
Code: | CONFIG_SND_HDA_GENERIC=y |
gives me the high cpu last. Compiling this thing (and CONFIG_SND_HDA_CODEC_REALTEK) as module works - even after loading the module.
What do we do with this bug? Report to upstream (kernel.org)? |
|
Back to top |
|
|
|