Почему при высокой активности дискового ввода-вывода тормозит даже то, что никак не обращается к HDD?

#cast i-rinat

Моих знаний mm в линуксе не хватает даже чтобы просто предположения о причинах данного поведения строить.

https://pf.natalenko.name/

Возьми бинарные пакеты, поставь. Если поможет - присоединишься к секте свидетелей post-factum'а

Спасибо за отклик. Может, знаете, кого скастовать в тред? Или сами сталкивались с этой проблемой?

Благодарю. Попробую и отпишусь в тред.

Не нужно никаких левых ядер.

Сначала подкрути vm.dirty_background_bytes и vm.dirty_bytes до разумных значений.

Сейчас попробую. Спасибо.

Кстати, вы не в курсе, в плане энергосбережения WiFi-модулей ничего сильно не менялось в ядре, новее 4.4? Начинал эту тему, но так и ничего

А iotop у тебя что показывает в этот момент?

Сначала подкрути vm.dirty_background_bytes и vm.dirty_bytes до разумных значений.

Попробовал значение в 2 мегабайта. Система действительно стала более отзывчивой.

Что пара пользовательских процессов на 100% забивают ввод-вывод

Собрал это ядро (4.9 lts). Выставил значения vm.dirty_background_bytes и vm.dirty_bytes. Стало заметно лучше. Виртуалка если и подлагивает в некоторых моментах, то только она одна. Очень признателен за рекомендацию!

Если ты на арче, то имело бы смысл сравнить с ядром linux-zen из [extra]. Набор патчей поменьше, зато собирать ничего не нужно.

Да, Arch. Спасибо, попробую. Описание выглядит интересно. Но, в принципе, и собрать не проблема - пакет из AUR, установочный скрипт сам спрашивает всё, что нужно.

Не в курсе, посмотри git log.

2, может, конечно, и слишком мало. Я бы поставил 40, а background — 20.

Емнип background и так ограничиватся в половину от dirty, можно только одно dirty указывать.

Ядро новое, 4.11.9

Не новое, именно в твое ситуации.

Ставь себе Linux inode 4.12.3-1-ARCH #1 SMP PREEMPT Sat Jul 22 15:32:02 UTC 2017 x86_64 GNU/Linux

И смотри вывод комманды cat /sys/block/sda/queue/scheduler

IO scheduler, что отвечает за отзывчивость системы - должен быть bfq.

Ссылка для информации - https://github.com/sirlucjan/lucjan-kernels/blob/master/lucjan-kernels-experi...

Нет.

Ставь себе Linux inode 4.12.3-1-ARCH

А в арче в ядре по дефолту есть патчи на bfq на singlequeue-устройств? Просто в ванильном ядре 4.12 bfq поддерживается только на multiqueue.

Вопрос интересный.

В Arch, пока отказались от поддержки bfq-sq и bfq-mq в core.

Ничто не мешает собрать самому. Не более 5 изменённых строк в config-x86_64.

bfq-sq в ядре вообще нет и не будет. Патчей отдельных тоже пока нет. -mq в Арче по умолчанию отключен, но можно включить без пересобирания (scsi_mod.use_blk_mq=1 ядру в загрузчике передать).

Приоритет им более низкий поставь или прерывания на одно ядро процессора.

Ты говоришь это тому, кто собирает кернел с BFQ и BFS с 2012 года.

Но то, что к HDD даже не планирует обращаться (тот же ввод с клавиатуры) - почему?

ты за был про keyloggerd?

Говорю, потому что вижу, что ты пишешь.

но можно включить без пересобирания (scsi_mod.use_blk_mq=1 ядру в загрузчике передать)

Домашняя тигрёнка - говорит, что кернел - таки придётся пересобрать.

Посмотри config.x86_64 с BFQ и узнай, сколько в нём сделано исправлений.

https://github.com/sirlucjan/lucjan-kernels

Разве?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/pa...

Почитай внимательно условие, где значение половинится (строка 436).

Ты пьян?

Твоя стандартная манера ухода в дискуссии.

«Мне нечего сказать по делу, значит - перейду к оскорблениям собеседников»

Жаль, но твои мысли, написанные в другой манере, парсер не берёт.

Согласен с парсером.

Иной раз, трудно переключаться с иврита/английского на русский.

Да, пожалуй, так лучше. Спасибо.

PS: отдельная благодарность за ядро! Понравилось, остался на нем :)

Благодарю.

Поставил 4.12-pf, все отлично. Но, как отписал в первом посте, проблема была решена скорее изменением значений параметров vm.dirty_background_bytes и vm.dirty_bytes. BFQ, конечно, тоже плюс.

Ссылка для информации - ...

Ссылка интересная!

0 для обоих достаточно разумны? Я правильно понимаю, что так можно выдёргивать флешки сразу после записи даже без вызова sync, но на любой чих, даже запись файлика в /tmp каждую секунду, сразу дёргается ЖД? А как это сочетается с настройкой энергосбережения ЖД, ограничивающей частоту обращений? И как влияет на производительность ОЗУ?

 143 /* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
 144 static unsigned long dirty_bytes_min = 2 * PAGE_SIZE;

Понятно?

Если оно в нуле, работает ratio.

А PAGE_SIZE откуда берётся?

Из железа.