Происхождение крекер-нити

В моей недавно установленной системе, использующей ядро 3.2, я вижу kworker-поток, который постоянно потребляет процессор. Я хотел бы выяснить, какая часть ядра / модуля создала эту рабочую очередь.

Как отследить поток kworker с именем, например, "kworker / 0: 3", до его источника в пространстве ядра?

Я пытался заглянуть в / sys / kernel / debug / tracing / events / workqueue, но не смог разобраться.

 Shahbaz01 июн. 2012 г., 11:21
Тогда может быть Суперпользователь. В любом случае, переполнение стека предназначено для вопросов программирования. Это не вопрос программирования.
 Anthon01 июн. 2012 г., 10:23
Процесс kworker обрабатывает вызовы ACPI из BIOS. В старых ядрах (<2.6.35 IIRC) их нет (по крайней мере, в моем ноутбуке с 2.6.32).
 Patrick B.01 июн. 2012 г., 11:09
@ Шахбаз, может быть, но мой вопрос не имеет ничего общего с Ubuntu.
 Shahbaz01 июн. 2012 г., 10:21
Ты можешь спросить об этом на Askubuntu

Ответы на вопрос(4)

Решение Вопроса

отве Я отправил на 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 - это пидк работника в списке процессов.

через некоторое время я нашел решение. На самом деле Anthon прав, именно ACPI-подсистема отправляет прерывания. На Мой system Я отключил следующие прерывания и kworker-thread успокоился.

echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08

Однако до сих пор не определили, что фиктивные IRQ приходят отgpe08 а такжеgpe1B.

 ballPointPenguin19 июн. 2013 г., 00:09
как ты пришел к этим прерываниям?
 Patrick B.19 июн. 2013 г., 13:34
IIRC, грубая сила. Где-то я обнаружил, что источник этих kworkers находится в подсистеме acpi, а затем отключил один gpe за другим и обнаружил, что эти два имеют эффект.
 JoseLinares19 дек. 2016 г., 14:01
ты можешь запустить grep. -r / sys / firmware / acpi / interrupts /, чтобы получить список прерываний с количеством срабатываний каждого из них. Те, которые имеют большие значения, вероятно, являются проблемными.

когда не подключен кабель - обходной путь

Имел kworker (вызывает kernel_thread_helper + 0x6 / 0x10?) Нить 1, активирующая 100% процессорного времени в течение 1 секунды каждые 5 секунд, только если ноутбук питается от кабеля. Нет проблем с питанием от батареи. Не имеет значения, если батарея полностью заряжена.

Это более или менее неожиданно вышло, так что я думаю, что последнее обновление Ubuntu было причиной (3.2.0-55-generic-pae сейчас).

Мы искали полдня, пытаясь выяснить, в чем причина, и пытаться отключить все прерывания acpi, что не имело значения.

Добавление GRUB_CMDLINE_LINUX_DEFAULT = ”acpi = off” в / etc / defaults / grub помогло в конце.

Как я обнаружил прямо сейчас, я добавил его с этими точными специальными кавычками юникода, которые могут объяснить несовместимость с «тихим всплеском» (с кавычками по умолчанию), который озадачил меня. Мне нужно разобраться с некоторыми другими проблемами (загрузочное меню не отображается, хотя я пытаюсь, настройка входа по умолчанию не используется ...), поэтому я оставлю это тестирование на потом.

PS: через неделю проблема возвращается (без перезапуска, только приостановка между). Там может быть корреляция с использованием мыши USB. Выключение питания / включение помогло (перезагрузка не). Выбросил все варианты grub. Я ожидаю, что проблема появится снова когда-нибудь.

PPS: Прошло некоторое время (полгода), но он вернулся снова после резюме от оперативной памяти. Никаких недавних обновлений, просто подключение / отключение питания, как я часто делаю. Нет USB-устройств подключен / отключен. Тотем работал (но ничего не играл) во время ожидания. Выключите / включите с подключенным кабелем питания сделалн помогите, выключите / включите при отключенном кабеле питания.

который обрабатывает рабочие очереди. Этот поток создается в файле linux / kernel / workqueue.c.

 Angus14 июн. 2012 г., 15:02
Это очевидно из вопроса, что он уже знает, что kworker связан с рабочими очередями, и хочет знать, какая часть ядра отвечает за его загрузку процессора. Указывать на workqueue.c бесполезно.

Ваш ответ на вопрос