> сколько времени читаются эти несчастные 4k?Читаются то недолго. Но если винч мечется по всему диску, желающих накопилось много, а 4K нужно не только тут, но и в десятке мест в иных закоулках - в целом все будет выглядеть довольно предсказуемо, "висят тряпочки".
Бандвиз HDD и прочие iops'ы в таком режиме жалки. Ну вот плохо винчи относятся к случайному доступу. И вот этот трэш хоть планируй, хоть не планируй. Шедулер чо, волшебный? Трабле механических дисков в том что они вообще плохо поддаются планировке из-за дикой разницы скорости линейного и рандомного чтения. Внутренняя трансляция LBA также означает что ты не знаешь насколько плох запрос сектора X vs X+1 000 000 на самом деле. Может, винчу достаточно голову переключить на соседний блин и он его в тот же оборот снимет. А может это в другой стороне блина. Винч это наружу не показывает.
> И, кстати, как вышло что их вообще надо доставать откуда-то, кто и зачем подискардил,
Кернель, конечно. Он имеет право выбросить неиспользуемые страницы. Что в своп, что просто уповая на возможность перечитать бинарь с диска. Кстати обработчик ctrl+c - наверное не самый горячий код программы.
> ведь в системе было не просто достаточно памяти - ее в разы больше чем
> занятая. Конечно же, -buffers.
Дык buffers всю и позанимали. А когда потребовалось, в 12309 требовалось пойти настолько далеко что заняться выжимкой буферов на диск. И оказывалось что это в определенной конфигурации может занимать аж минуты. Первым повиснет "провокатор" такого запроса памяти, а пока его будут окучивать - и другие успеют подтянуться, если это в минутах измерялось. И будут они всей толпой курить бамбук пока им кернел память накопает за счет buffer'ов, которые оказывается надо было слить, а оно и займи минуты. Интерактивность идет в пень - какая интерактивность, если все колом на попытке получить свой кус памяти? А дергавшийся юзер еще добавит желающих на кус памяти.
...поэтому одни мудрые програмеры (виндозные btw) как-то сказали мудрую вещь: если компьютер тормозит, НЕ ДЕРГАЙТЕ ЕГО. Прозрачно намекая что от дерганий все только усугубится.
> почему до 16й версии включительно не забивалось, а в 18й или в
> 22 (не знаю точно) - на том же самом диске и
> на той же самой операции вдруг началось?
Мне как-то трудно сравнивать что там было бы на 18 или 22 версии в моих конфигах здесь и сейчас - даже если я найду эти ядра, они не поднимут мое железо и останутся без ФС. Так что если это знание и имело ценность, это было много лет назад. А ковать надо все-таки пока горячо.
Я могу сказать что в моих конфигурациях у меня нет крупных системных проблем с актуальными ядрами. И я даже померял вон тому чуваку с его memhog'ом пруфец что его чудо расстреливается за 5 секунд oomkiller'ом. Без втыкания в шоу минутами. И глядя на такой прецедент я позволю себе думать что все эти страшные сказки не являются каким-то принципиально неотъемлимым атрибутом работы линуксного кернела, скорее атрибут дурной конфигурации где сделали что-то неудачное. Я видел не менее неудачные вещи и с, допустим, виндами, где на систему можно было пялиться 5 минут без какой либо реакции на потуги юзера.
> Диск на большинстве личных компов, если ты не в курсе, один.
Для торентов и прчих активных файловых операций таки имеет смысл отдельный винч. Потому что пока торент вкалыввает, IO занят, да еще эта активность может довольно круто фрагментировать винч. И если ты думаешь что это только в линуксе - ога, юзер тут удивлялся что винда раньше менее минуты стартавала, а теперь 3+. Оказывается он торентов под завязку на ntfs накачал. И там такое месиво вышло... что теперь система при загрузке по всем закоулкам телепается. Ну и вот грузится 3 минуты. И таки юзер допер снести торенты на внешний винч, отдефрагать наконец этот ужас за ночь - стало явно приличнее, и система в целом работает заметно менее печально.
На SSD это не актуально, по поводу чего все кто в здравом уме и юзают SSD системным. Это многократно улучшает ощущения от компа хоть с какой системой. Но вот торренты на него складывать ... дороговато в пересчете на гиг. И да, на поржать, быстрая флеха в usb может при сидировании сделать механический винч если это не подперто адским кэшом. Она seek-ом не страдает.
> Э... собственно, на большинстве серверов он тоже как бы один, поскольку рэйд.
В обычном десктопнике это разве что от общесистемной глупости бывает. Ну, продаван то собирает как дешевле и больше навар, ему плевать что с юзером будет. А если это самому собирать, для себя - можно наверное и сделать себе хорошо. А хотя-бы и доплатив немного за свой комфорт.
В сервере ... другие паттерны доступа, другие требования и серваку явно не придется читать какую-нибудь иерархию меню и 20 иконок по всему диску. Так что и туповэйтить это никто не будет. Как и запускать какойнить либреофис или кад с кучей либ в произвольные моменты времени.
Торенты серваками грузить можно. И я скажу одну вещь: именно быстро, именно сидить, именно в полку - сильно перспективнее с SSD. На механике ... торенты постепенно могут вызвать довольно неприятную фрагментацию, особенно если активно гонять и забить под завязку. И вот это выглядит вообще совсем не круто. При том в эпоху без e4defrag и btrfs fi defragment это было очень неприятным подарком судьбы - после этого остается довольно проблемный сервак с довольно паршивым перфомансом и единственное что с ним можно сделать разумного - пересоздать файлуху, что бывает не совсем удобно.
> у нас elevator был еще до п-ца с cfq и прочими снами разума.
Сны разума все больше ориентируются на SSD. Их и можно осмысленно планировать по бандвизу/iops, и в адский штопор они не скатываются, и латенси на порядки меньше, и рандомный доступ им не мешает особо, по крайней мере на чтение. А жестаки разумно планировать, при том что мы даже геометрию не знаем и понятия не имеем насколько плохо сгруппировать вот этот запрос с вон тем и за сколько это скорее всего закончится, и этот ответ разный для разных жестаков в зависимости от того как на конкретно их геометрию это попало...
> Кстати, переключение в deadline слегка ослабляло накал п-ца. Но, опять
> же - слегка. То есть дело не в deadline.
По состоянию на сейчас я не вижу никакого особого "накала проца" при io. Даже блин на одноплатниках с ARM малохольным. Вероятно, за столько лет реалии все же здорово фалломорфировали, и в железе и в софте. И какая мне радость с знаний про 2.6.18 и то железо? У меня нет ни того ни другого. И более того - я не понимаю откуда следует что те алгоритмы и решения хорошо бы работали здесь и сейчас.
> синхронный read тут же отберет cpu, ничего не повиснет, кроме самой задачи,
Ну так если кто не понял - только задачи и висят. Просто если действо дофига, за это время еще желающие поднабегут с теми же запросами. И все сколлапсирует в том плане что общая латенси будет никакая.
И сейчас таки есть некоторые отличия:
1) В ядре радикально меньше блокировок.
2) У процов часто более 1 ядра.
3) Ядро "heavily threaded" и все такое.
4) Железо таки тоже в массе своей иное, PIO4 мало кто уже использует.
5) Кернел можно собрать как full preempt, так что туповэйтящее ядро может само себя выставить и заняться чем-то более интересным. Для десктопа это очень рекомендуется с точки зрения латенси.
А, если я не говорил я билдую себе ядра сам. И на десктопах это full preempt, tickless ядра, конечно. Однако даже все это не очень поможет если заставить винч телепаться во все стороны и нагнать толпу желающих чтобы это усугубить.
> которая останется грустно ждать этого read. Это хорошее и правильное поведение
> - все остальное получит шанс как-то пошевелиться, но его как раз сломали.
На _моих_ юзкейсах и конфигах я вроде не вижу ничего такого нелогичного и запредельного. А если кто видит - ну так пусть раскопает WTF. Девы себе тоже если что ssd накупили, они что - раки ждать в цать раз дольше файловые операции при девелопменте? И естественно у них все ок, иначе это было бы починено в момент :)
> Иначе бы своп снова обрел хоть какой-то смысл. Но в нем даже
> на nvme смысла нет.
Мне zram нравится. С одной стороны выпихивает откровенно холодное барахло в сжатый вариант. С другой если оно все же надо и/или worst case душняк памяти все же не вызывает ничего близко похожего на тот ад который с swap можно получить.
