Жуткий своппинг (BTRFS) [Решено]

Приветствую!
Довольно давно наблюдаю одну неприятную проблему на последнем дистрибутиве Kubuntu. При исчерпании свободной памяти при попытке вытеснить данные в своп машина просто встает колом. Виснет даже курсор и изображение на экране. Только изредка интерфейс кратковременно оживает...
Данная проблема проявляется на двух совершенно разных машинах. Объединяет их только два фактора. Это SSD и файловая система BTRFS для корня. Так что не думаю, что это проблема по железу. Причем совершенно неважно на SSD находится раздел со свопом или нет (на второй машинке дополнительно есть еще HDD). sysctl.conf абсолютно дефолтный. Своп явно задействован и отображается по команде free -h.
Ума не приложу в чем дело. Может кто подскажет куда копать?

UPD 12.09.19:
В последнее время проблема широко обсуждается в узких кругах. Много жалоб именно на связку с BTRFS, народ массово рапортует о решении проблем со своппингом при откате на ext4. Даже предлагается очередной патч ядра для решения проблем со свопом.
Я тоже долго жил с этой проблемой, но в конце концов, перед окончательным откатом на ext4 решил предпринять последнюю попытку найти решение и решение нашлось! Собственно, для "потомков" оставлю это здесь:
Очевидно, что BTRS фундаментально отличается по внутренней структуре от классических файловых систем и не в последнюю очередь требованиями к памяти и работе с ней. По всей видимости, это и стало причиной множества проблем. При попытке выделения большого объема памяти, превышающего физически доступную, ОС начинает интенсивно сокращать файловый кеш, а затем агрессивно вытесняет страницы памяти с низким приоритетом в своп. Вот тут-то и кроется проблема! Важно в КАКОЙ момент это происходит. В общем случае, при дефолтных настройках системы, это происходит слишком поздно и для нормальной работы файловой системы просто не остается достаточных ресурсов в виде оперативной памяти и файлового кэша. В моем случае машина могла не выйти из своппинга и за всю ночь! Если же физической памяти недостаточно, но ее выделение выполняется маленькими объемами, то машина еще справляется, наглухо подвисая на 1-10 минут до освобождения необходимого объема памяти...
Отсюда следует, что надо заставить ядро выгружать память в своп несколько раньше, чем системе поплохеет. Иными словами, отрегулировать агрессивность своппинга. А какой параметр у нас отвечает за это? Неправильно! Это не vm.swappiness вопреки распространенному заблуждению!
Собственно, большое количество дезы в сети на предмет настройки работы с памятью в Linux-системах и завело меня в тупик. А надо было просто читать официальную документацию...
Томить не буду, ларчик просто открывается. За то, когда будет вызываться kswapd и, соответственно, насколько агрессивно будет выполняться выгрузка памяти в своп в большей степени отвечает параметр vm.watermark_scale_factor. По умолчанию его значение 10, это означает, что воркер ядра, ответственный за выгрузку памяти в своп, включается только тогда, когда осталось всего 0,1% свободной физической памяти и в нашем случае, при интенсивном выделении памяти, этого оказалось катастрофически мало...
Максимальное значение этого параметра 1000, что равно 10% свободной физической памяти, но такое значение я рекомендую выставлять только при медленном свопе и малом объеме памяти. На машине со свопом на SSD будет более чем достаточно значения в 5000. Собственно, именно при таком значении моя проблема была полностью решена. Теперь машина может лишь изредка фризить при активном задействовании свопа, что совершенно нормально!
Хочу также заметить, что при дополнительном использовании ZRAM картина становится еще лучше, редкие фризы пропадают почти полностью! А вот ZWSAP почему-то в значительной степени нивелирует эффект от принятых мер, но тем не менее ситуация остается далека от той, что была при дефолтных настройках системы.
Как итог, я опять могу беззаботно открывать десятки и сотни вкладок в браузере, параллельно работать в виртуалке и спокойно крутить в Блендере модели с миллионами полигонов.
Enjoy Linux!

UPD_2:
Полезные ссылки:
1) Справка по опциям sysctl для менеджера памяти https://www.kernel.org/doc/Documentation/sysctl/vm.txt
2) Обсуждение бага на kernel.org + ссылки на патчи https://bugzilla.kernel.org/show_bug.cgi?id=196729
3) Некоторое количество полезной информации также найдено в статье на Хабре и комментариях https://habr.com/ru/post/344836/#comment_10569644