Комментарии 28
Обалденный перевод. читается круче любого детектива. и такая неожиданная развязка...
Да, блог Брендана Грегга всегда интересно читать. Один легендарный пост про подсчёт load average чего стоит.
хм. а теперь кто-нибудь объясните мне, зачем ZFS вообще была включена в ядре, если она не использовалась?
Как-будто вот все пересобирают под себя постоянно ядро, включая и выключая необходимые фичи. Тем более что фиг угадаешь какая фича будет необходима через полгода. Была себе там поддержка zfs - ну, пусть себе будет. Пока мы её не используем - она ведь не должна никак влиять, правда? Баг был именно в zfs, которая заставляла "платить" за себя даже того, кто её не использовал.
Да, возражений к тому, что бага в ZFS была — нет. Но всё же кажется её можно было обойти проще: rmmod zfs
Если у них ядро используется в 50-и разных местах, то может быть удобнее иметь одно ядро со всеми включенными опциями, чем 50 разных сборок.
Кроме того, наверняка тот, кто это ядро настраивал рассчитывал что драйвер файловой системы будет использоваться только если она смонтирована. Это довольно разумное предположение.
Еще бы узнать, что вызывает на винде System Interrupts загрузку проца в 100%, когда система не используется. Не удивлюсь если там что-то похожее.
У меня после того как залил ноутбук помогает отключить контроллер USB в device manager
Руткит с майнером?
А это и не было смехом, кстати.
Тоже процесс system выжирает cpu. Причем после того как пытается понизить частоту до 0.8 ггц, типа сэкономить, загрузка цп поднимается до 100% и висит так часами, ревя вентилятором. Частота подростает при любой пользовательской активности и загрузка цп падает в 0. Так и не смог победить, видать особенность асуса... Вирусов тоже не нашлось. Может подскажете что?
ну я не думаю, что после переустановки винды там это сразу появляется. тем более без подключения интернета. прикол в том, что там уйма причин, почему это возникает. но при этом в винде нет нормальной софтины, которая бы точно указала на причину.
В Windows прерывания обычно обрабатываются в 2 стадии.
Первая — это первоначальная обработка прерывания, на уровне IRQL устройства, блокирующая менее приоритетные прерывания. Руковдства рекомендуют делать ее максмально краткой, и она обычно ограничивается фиксацией состояния устройства и, если дальнешая обработка необходима — постановкой элемента для этого в очередь отложенной обработки (DPC). Процент времени процессора, приходящийся на эту стадию показывает счетчик монитора производительности %Interrupt time.
Вторая — эта самая отложенная обработка, которая выполняет основную работу по обработке прерывания. Она производится на уровне IRQL DPC/Dispatch (на том же, на котором выполняется планировщик) при разрешенных прерываниях. И процент времени процессора, приходящийся на эту стадию показывает другой счетчик монитора производительности — %DPC time. Так что в системе есть два разных счетчика, но некоторые утилиты отображения информации могут их свести в один.
Если велик именно %Interrupt Time, то дело — в слишком часто приходящих прерываниях (для скорости их прихода, кстати, тоже сеть счетчик). Это может быть неисправное устройство или, к примеру, сетевая карта в неизбирательном (promiscuous) режиме в хорошо загруженной сети.
Как искать такоеустройство без отладчика (или последовательго отключения подозрительных устройств) я даже и не знаю.
DPC же могут порождать не только прерывания, но и другие механизмы ядра. Там думать надо по месту.
Можно брать их по очереди, но разработчик решил, что лучше выбрать наугад.
Криптографически безопасный рандом.
Интересно, на кой ляд разработчику нужен был именно криптографически безопасный генератор случайных чисел, если его цель — просто выбирать для обработки очереди с равной вероятнностью.
Генератор псевдослучайных чисел — простой(на коленке написать можно, если что) и быстрый ему бы вполне подошел.
ZFS таинственным образом поедает мой CPU