> а локап-то откуда?

Ну смотри, душняк памяти. Кернель выкидывает паги его любимой апликухи из рамы, с мыслью подчитать потом из файла, коли так можно было.

А когда юзер пытается поюзать апликуху - ну, собссно, она ловит 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 мощный комп с дофига всего запущенного, чтоли.