# [solved] kworker runs on 30%

## musv

Hi there, 

I just noticed, that one kworker process runs constantly on 30% of cpu last. 

top tells me:

```
  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.gzLast edited by musv on Wed Nov 30, 2016 1:49 pm; edited 1 time in total

----------

## tholin

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.

----------

## musv

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. 

```
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)?

----------

