01 июн. 2012 г., 10:16 отPatrick B.

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

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

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

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

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

19 февр. 2013 г., 10:07 отCommunity

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

24 окт. 2012 г., 20:31 отPatrick B.

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

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

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

27 окт. 2013 г., 19:18 отaxm

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

Имел 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-устройств подключен / отключен. Тотем работал (но ничего не играл) во время ожидания. Выключите / включите с подключенным кабелем питания сделалн помогите, выключите / включите при отключенном кабеле питания.

01 июн. 2012 г., 16:48 отmohanreddykv

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

ВАШ ОТВЕТ НА ВОПРОС