LA 0.8 при простое

Сказал как отрезал. Держишь в курсе или забыл что-то спросить? О_о

Исправил:

Как найти кто дает этот LA?

top/atop/htop/etc пособирай статистику - найдешь ответ.

usb_hub

попробуй usb-stack отключи, понаблюдай.

top/htop - бесполезно.

powertop - интересно, но без результата.

perf - без результата.

mpstat - без результата.

посмотри через fatrace
может покажет чего

fatrace - бессмысленно. I/O при этом отсутствует.

google://usb_hub_wq
по первой же ссылке - Excessive CPU usage in kworkers usb_hub_wq and pm
совпадение? не думаю (с)

Кто такой «kworker/11:3+usb_hub_wq»?

Поток в ядре

У меня оно cpu не жрёт.

Но LA 0.8 практически постоянное.

Нужна какая-то статистика от планировщика. Это он LA считает.

ладно, а перезагрузиться можешь?
предлагаю попробовать передать ядру параметр usbcore.nousb
просто посмотреть, опустится LA или нет

Точно! Как же я раньше не догадался ? :)

С кучей событий от cpufreq/ondemand я уже разобрался. Но ничего не изменилось.

Я уж тогда на время kvm/usb_hub отключу.

PS/2 разъёма на матери нет.

Ты какой-то агрессивный. Сказали же тебе, есть top, в нем колонка TIME, которая показывает, сколько времени процесс времени сожрал.

Еще раз - CPU оно не жрет. Система в простое (cpu,disk,network).

Но LA 0.8.

Я помню, что в онтопике состояние «D» влияет на LA.

Я уже начал понимать, что нужно какую-то статистику от планировщика, но есть сомнения, что её можно получить для ядерного треда.

Я помню, что в онтопике состояние «D» влияет на LA

сеть кстати тоже влияет

В dmesg пусто? Ещё можно посмотреть счётчики прерываний, может там будет что-то быстро растущее, попытаться определить от какого устройства.

irqtop смотрел. Пересобрал ядро с CONFIG_HZ=250 вместо 1000.

Ничего не поменялось.

Отключил usb-хаб. Ничего не изменилось :(

Попробуйте запустить на несколько секунд в цикле ps и grep'ать из его вывода всех в состоянии ″D″, может кто-нибудь всё время ждёт.

Ещё есть PSNAPPER (psn), он и по потокам ядра что-то показать может. Может дойдёте до «Off-CPU flame graph» https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html или до ftrace...

psn показал интересную вещь

=== Active Threads ========================================================
 samples | avg_threads | comm                     | state                  
---------------------------------------------------------------------------
     596 |        0.52 | (kworker/*:*+usb_hub_wq) | Disk (Uninterruptible) 
     118 |        0.10 | (apcupsd)                | Disk (Uninterruptible) 

Большую часть времени он проводит вот так:

cat /proc/`pgrep -f usb_hub_wq`/{stat,stack}

24049 (kworker/14:0+usb_hub_wq) D 2 0 0 0 -1 69238880 0 0 0 0 1 2 0 0 20 0 1 0 125086 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 1 0 0 17 14 0 0 0 0 0 0 0 0 0 0 0 0 0
[<0>] msleep+0x2d/0x40
[<0>] hub_port_reset+0xdd/0x760
[<0>] hub_event+0x3f3/0x1500
[<0>] process_one_work+0x1d5/0x3b0
[<0>] worker_thread+0x50/0x3e0
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30

Видимо это неисправимо. Поробую я откатиться на 5.10 или обновиться на 6.1 которая объявлена LTS

Лечить по фотографииДиагностировать хардварные проблемы по переписке – дело безнадежное.
Мне вот в последней моей теме ничем тут в похожем вопросе помочь не смогли.

Видимо это неисправимо.

В большинстве случаев при наличии времени и необходимости баг удается найти.

Я бы поступил так:

1. С помощью динамической трассировки (libbpf или systemtap) локализовал бы точно, в каком месте кода ядра затык;
2. разобрался бы, что делает этот код и код, его окружающий;
3. изучал бы до полного просветления даташит на оборудование, которым этот код управляет.

Я бы указал в теме точное название оборудования и прикрепил dmesg/lspci -vv целиком. Может, кто-нибудь когда-нибудь наткентся. Авось.