В моей недавно установленной системе с использованием ядра 3.2 я вижу поток kworker, который постоянно потребляет процессор. Я хотел бы узнать, какая часть ядра/модуля создала этот рабочий вопрос.
Как отслеживать поток kworker, названный, например, '' kworker/0: 3 в его начале в пространстве ядра?
Я попытался заглянуть в /sys/kernel/debug/tracing/events/workqueue, но не смог понять.
(Мне кажется, что это довольно не по теме, но здесь ответ Я отправил на unix.stackexchange.com.)
Я нашел этот поток на lkml, который немного отвечает на ваш вопрос. (Кажется, даже сам Линус был озадачен тем, как узнать происхождение этих потоков.)
В принципе, есть два способа сделать это:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
Для этого вам понадобится ftrace для компиляции в вашем ядре.
Это будет выводить все потоки, и это полезно для отслеживания нескольких небольших заданий.
cat /proc/THE_OFFENDING_KWORKER/stack
Это приведет к тому, что стек одного потока будет выполнять большую работу. Это может позволить вам узнать, что вызвало этот конкретный поток для зависания процессора (например). THE_OFFENDING_KWORKER - это pid kworker в списке процессов.
Итак, через некоторое время я нашел решение. На самом деле Anthon прав, это ACPI-подсистема, которая отправляет прерывания. В моей системе я отключил следующие прерывания, и kworker-thread успокоился.
echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08
Однако до сих пор не были определены, какие фиктивные IRQ появляются от gpe08 и gpe1B.
kworker/сторожевой таймер, вызывающий высокую нагрузку, когда не на кабеле питания - обходное решение
У вас есть kworker (причина kernel_thread_helper + 0x6/0x10?) thread 1, до 100% от процессора в течение 1 секунды каждые 5 секунд, только если ноутбук питается от кабеля. Нет проблем с питанием от батареи. Не имеет значения, заряжена ли батарея.
Это было более или менее неожиданно, поэтому я думаю, что недавнее обновление Ubuntu стало причиной (3.2.0-55-generic-pae сейчас).
Ищет полдня, пытаясь выяснить причину первопричины и попытаться отключить все прерывания acpi, что не имеет значения.
Добавление GRUB_CMDLINE_LINUX_DEFAULT = "acpi = off" в /etc/defaults/grub помогло в конце.
Как я выяснил сейчас, я добавил его с помощью этих специальных специальных кодов Unicode, которые могли бы объяснить несовместимость с "тихим всплеском" (с котировками по умолчанию), который озадачил меня. Я должен изучить некоторые проблемы с grub (меню загрузки не отображается, но я пытаюсь, не используется настройка по умолчанию, не используется...), поэтому я оставлю это тестирование позже.
PS: через неделю проблема вернется (без перезапуска, только приостановка между ними). Возможно, существует корреляция с использованием мыши usb. Power down/power up помогли (перезагрузка не была). Бросил все варианты grub. Я ожидаю, что проблема появится снова когда-нибудь.
PPS: Взял некоторое время (полгода), но он снова вернулся после возобновления работы с бараном. Нет недавних обновлений, просто подключая/отключая питание, как я часто это делаю. USB-устройства не подключены и не подключены. Если во время приостановки выполнялся тотем (но ничего не играл). Power down/power up с подключенным силовым кабелем не помогло, отключилось питание/питание при отключенном кабеле питания.
kworker - это поток ядра, который обрабатывает workqueues. Этот поток создается в файле linux/kernel/workqueue.c.