> а локап-то откуда?Ну смотри, душняк памяти. Кернель выкидывает паги его любимой апликухи из рамы, с мыслью подчитать потом из файла, коли так можно было.
А когда юзер пытается поюзать апликуху - ну, собссно, она ловит page fault, как обычно -> кернель идет за страницей в бинарь апликухи. И пока оно там ее вынет, особенно ежели сие на механическом диске, да для десятка апликух... ну апликуха и висит тряпочкой. А куда она денется без потребной для продолжения работы страницы? :)
> ну да, мы вот этот цирк вполне наблюдали на том примере, который
> тут в конце комментов был дан.
В случае с SSD баг можно рассмотреть за фичу :P. И ты же понимаешь что разработчики себе не враги и давно накупили SSD. Вот оно их и не парит.
> оно и так уже на диске лежит.
Проблема с этим вот в чем: ежели мы хотели low latency систему, которая либо отрабатывает, либо обламывается за обозримое время, даже вырубить своп таки не пролечит вот это на 100% т.к. останется этот механизм. Это может быть немного назойливо.
Кому принципиально, я знаю минимум 2 хака на тему:
1) Вообще вырубить свопы в конфиге кернеля, это вроде и данный механизм выносит, если не путаю.
2) LD_PRELOAD всем процессам и оттуда mlockall, чтоли, какой. Сие сделает что запрошено, но есть некие побочные эффекты...
> Понятен, что в случае когда мы не планировали свопинга вообще -
...мы таки все равно можем получить "computer is thrashing" в объеме превышающем желаемый.
> буферный кэш не помешал бы (у zfs arc такой, кстати, есть
Только гули толку, без плотной интеграции с остальным mem management оно только все испортит лишний раз. А кто ж его в zfs то с mem management линя то настолько плотно будет дружить?
> Но совсем виснуть-то нахера же ж ?
Если страниц памяти для апликухи нет - она не может работать :). Это не полный взвис, просто деградация перфоманса. Но это в назойливом виде реально получить на механическом диске vs мощный комп с дофига всего запущенного, чтоли.
