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

Только описанная ситуация вполне подходит под типичный юзкейз - открыл в дополнение жрущей виртуалочке браузер почитать опеннет - и на тебе.

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

Собственно, я это воспроизвожу где-то раз в месяц на старенькой системе 2010года с двухядерным ЦПУ и 8ГБ ОЗУ.
Там же, до недавнего разжирения еср-лисы, собирал ее c "правильными" опциями.
C WRKDIRPREFIX на 5ГБ tmpfs, без свопа, с отрытым браузером, почтовиком,  и прочим. И llvm включительно 8.0 собирал в том же tmpfs. На последних версиях (то ли лисы, толи llvm, то ли обоих), под конец сборки для линковки приходилось закрывать жирную лису и вроде бы даже увеличивать tmpfs, иначе линковка завершалась с "оом". В общем, загрузка ЦПУ и ОЗУ, подходящая под описание и совсем не синтетикой - но без чудо-ZFS.

А, еще, пару раз, почитав опеннет, пробовал запустить 4x-6x "python -c 'while True:pass' - правда, это больше на посмотреть разницу между дефолтным
kern.sched.interact=30 и 10 в отзывчивости GUI. Никаких фризов и дедлоков не наблюдал.
О своем отношении к ZFS еще раз писать не буду - тут вспоминается пословица про крейсер и небольшую, но гордую страну. В итоге и крейсер прос^Hржавел вконец и инфраструктура страны обветшала и жители большей частью слиняли.

Разъясняю особо: "ненаблюдал" != "их нет, вы все врети". Но есть разница - наблюдать при достаточно типичном и легковоспроизводимом юзкейзе или же если для наблюдения придется натянуть лыжи, противогаз и забраться в гамак.

А "дедлок" из-за нехватки памяти воспроизводится довольно просто:
1. не ограничивать vm.kmem_size размером (ОЗУ - пара сотен МБ)
2. отключить своп (впрочем, включенный вряд ли сильно поможет)
3. примонтировать tmpfs или MD с размерами >= ОЗУ (размер придется задать ручками, по умолчанию максимальным размером будет половина свободной памяти)
4. заполнить его записью чего угодно
наблюдать за тем, как ООМ будет прибивать все нафиг, в том числе и локальные или удаленные сессии.
Однако, если немного повезло, то сессию вместе с "заполнителем" отстрелило достаточно рано, чтобы осталось памяти на ssh ffo@bar 'cmd' для починки.

Еще не раз видел, как при сильной фрагментации памяти (привет современные браузеры после пары дней работы), т.е.
> в системе приличное количество  свободной но не "свободной с ее точки зрения" памяти (чтобы in-kernel тредам было чем заняться, но они не смогли завершиться достаточно быстро

pagedaemon начинает неплохо отжирать CPU без какого либо эффекта, а вот оом киллер как раз не спешит - ведь памяти достаточно. Лечится только перезапуском браузера.
Но вот чтобы еще и было особым образом отожрано все CPU (и это, повторю, на весьма средней даже по "консумерским" меркам еще 10-летней давности, системе) и наступил этот вот описанный "белый и пушистый" deadlock - ни разу не совпало.

Т.е. опять или достаточно специфичная ситуевина или же вообще, очередные
> (привет, abd!)

"приветы" из реализации ZFS.