> Ну вот описаную ситуацию

ну потому что он все неправильно делает.
buffer cache настал каюк, да, а про то что в ядре полно мусоросборочных тредов, запускающихся по таймеру - не подумал.

> А давай!

ну подсказка - см выше. Собственно, во времена ядер 2.0 и очень медленных дисков был прекрасный способ посмотреть на ядерные дидлоки - cd /usr/src/linux ; make -j zImage
(тут тебе и кэши, и память, и своп, и отсутствие у cpu времени на всякую периодическую мусоросборочную ерунду ;-)

Иногда оно раньше успевало навернуться по нехватке памяти, а иногда нет. Сейчас такой эффект уже так просто не получишь, но если стараться - то тоже можно.

Собственно, на ту же самую проблему я в 17м году нарвался во фре, только там хватило -j4 + zfs на медленной системе (сборка libllvm очень, _очень_ cpu intensive процедура)
Причем дидлок-то не в zfs (точнее, и в ней тоже был, но его, с великим трудом, удалось, вроде бы, извести), она просто позволяла лучше рассмотреть его наличие. С тем же успехом можно было сожрать ту же память сетевыми буферами, просто воспроизводить в разы геморройнее.

Механизм все тот же - отожрать cpu, иметь в системе приличное количество свободной но не "свободной с ее точки зрения" памяти (чтобы in-kernel тредам было чем заняться, но они не смогли завершиться достаточно быстро, как в тех ситуациях, которые предполагали и которые проверяли авторы) с максимальной фрагментацией (привет, abd!) и резко этой памяти захотеть.