post-factum ты защищаешь все файловые страницы, в том числе грязные. При достаточном объеме грязных страниц защита ломается. Защита грязных нам вовсе не нужна. Новая версия защищает только чистые.

прям как заголовок на алиэкспрессе :3

Еще вариант:

Защищаем чистый кэш файлов под давлением памяти для предотвращения пробуксовки и живой блокировки.

Расскажи, как ты это тестируешь? Под какими нагрузками, и насколько улучшается работа системы? Под какими нагрузками она, наоборот, ухудшается?

Во-первых см демо https://github.com/hakavlad/le9-patch#demo

ФС на HDD, со свопом на zram или без свопа. Нагрузки - циклы tail /dev/zero и самописная синтетика на питоне.

Более реалистичные нагрузки: вкладки браузера, блендеры, копиляции. Со свопом на zram эффект отличный и детектится метриками PSI - снижается давление IO.

См канал https://www.youtube.com/channel/UCogKx3pHgAqSvaWkEjMTJfA/videos

Нетехнические разговоры о Linux/Unix.

А где еще обсуждать? Нет раздела Kernel.

Тред свежий был https://marc.info/?t=161734713700002&r=1&w=2

Человек в рассылке жалуется на всё ту же проблему. К счастью, решение есть.

какое отношение к 12309?

Жесткая защита некоторого количества чистого кэша исправляет 12309 при любом размере dirty (если своп не на HDD).

Для технических разговоров, не подходящих ни в один специализированный техраздел, внезапно, есть отдельный техраздел.

Занятно. Спасибо за ответ

Затрахали вы своими маятниками ☺.

А что уважаемые кернеделы думают на тему изменений в MM?

https://lkml.org/lkml/2021/3/31/966

if (reclaimable_file > dirty)

Разве ^^ может быть иначе? Почему здесь эта проверка?

И да, что будет, если немного задрать vm.min_unmapped_ratio без твоего патча?

Я не слишком-то кернедел, но думаю баги и уязвимости будем выгребать много лет.

Идея классная, как по-мне. Жаль только что надо патчить ведро. Эх вот-бы было возможно сделать что-то подобное в виде внешнего модуля или даже просто обычного бинарника… Мечты, мечты…

Попробую так: [1]

[1] http://ix.io/2Vlw

Похоже, что ничего, по крайней мере, в моих тестах.

Может:

[00:10] <post-factum> so, nr_file_dirty can never exceed (nr_inactive_file+nr_active_file+nr_isolated_file)?
[00:13] <vbabka> ugh, never say never
[01:01] <willy> can you read all those variables atomically?
[01:33] <vbabka> yeah atomically, one by one
[03:55] <willy> right, so it can exceed because they can be read out-of-sync

Попытка №2: [1]

[1] http://ix.io/2VmE

Ну вот после такого ревью почти для каждого патча — ты прав.

Это #kernel в ирке?

https://lkml.org/lkml/2021/3/31/966

Давно пора. 4K - пережиток семидесятых.

#mm в OFTC.

Ну, работает, вроде как.

4K в основе никуда не денется, к сожалению. По крайней мере, в обозримом будущем.

как тестировал?

Чуть позже стори напишу.

А ведь когда-то было вот так:

Anybody who needs more than 64Mb/task - tough cookies

mon.py + tail.

•  	clean_file = ULONG_MAX;
  

Почему не 0?

•  if (unlikely(
  

На самом деле отрицательный clean получить легко, если знать как. Например, копир на флэшку + tail /dev/zero - при этом происходит долгий сброс грязи, ООМ не приходит, давление высокое, а dirty периодически превышает reclaimable. Максимум на четверть мегабайта в моих опытах.

if (!cgroup_reclaim(sc)) {

Почему вычисляешь clean в пределах этого условия?

Разве ^^ может быть иначе? Почему здесь эта проверка?

Сначала находил чистые как AF+IF-dirty.

В итоге уходил в минус до 2-3 Мегабайт.

Потом добавил isolated - уход в минус сократился, уходит в минус макс на четверть МБ.

Так что уход в минус - экспериментальный факт, и не такая уж редкость (особенно если специально воспроизводишь - копирование+стресс).

По аналогии с file_is_tiny.

Почему не 0?

Потому что в этом случае сравнение для file_is_min всегда будет позитивное. Я не уверен, что защита должна срабатывать в этом случае.

На самом деле отрицательный clean получить легко, если знать как. Например, копир на флэшку + tail /dev/zero - при этом происходит долгий сброс грязи, ООМ не приходит, давление высокое, а dirty периодически превышает reclaimable. Максимум на четверть мегабайта в моих опытах.

При нормальной жизни такого не бывает, только в случае дикого memory pressure, которое unlikely.

заигноришь половину лора, и токсы так даже и ничего, техничные=)

Но ведь file_is_tiny нам не указ. Почему мы должны игнорировать восстановление за пределами !cgroup_reclaim(sc) ?

Думаю кучу вопросов можно поднять в рассылке, и предложить RFC PATCH.

Почему не 0?

Представь, если у тебя dirty 205 MiB, reclaimable в сумме — 200, а порог — 100. Это что же, при таком раскладе порог уже должен срабатывать?

Можно сделать иначе:

		if (unlikely(reclaimable_file < dirty_file))
			clean_file = (sysctl_unevictable_file_kbytes_low + sysctl_unevictable_file_kbytes_min) / 2;
		else
			clean_file = reclaimable_file - dirty_file; 

В таком случае порог будет, но мягкий.

Представь, если у тебя dirty 205 MiB, reclaimable в сумме — 200, а порог — 100. Это что же, при таком раскладе порог уже должен срабатывать?

Предполагаемый clean тогда будет в пределах 5М, что ниже 100М.

Вообще ожидается, что погрешность рне более МБ с учетом isolated.

Еще вопрос - что делать с writeback. Он файловые? Они учитываются как recl или как dirty? Их объем обычно не более 4МБ.

Без их учета вроде все ок. Но вопрос все равно остался.

Предполагаемый clean тогда будет в пределах 5М, что ниже 100М.

Во-первых, со знаком минус. А у нас unsigned long, если что.

Во-вторых, почему 5? Я не шучу, здесь строгая математика неприменима, потому что из-за неатомарности показателей мы просто получаем неопределённость, при которой либо можно просто сказать «окей, я пас» (aka ULONG_MAX) или «окей, все вон» (aka 0), ну или «тише там» (aka мягкий порог).

Что нам ближе?

Вчера об этом тоже задумался. Судя по коду, PGDAT_WRITEBACK не исключает PGDAT_DIRTY, поэтому нам нужно трекать только dirty.

Во-вторых, почему 5

Не 5, а НЕ БОЛЕЕ 1 МБ, судя по опытам, по крайней мере на моей машине.

Если recl < dirty - явно имеется дефицит clean. Тогда почему б не сообщить, что clean=0?

Думаю просто стоит задокументировать, что вычисление clean имеет погрешность, предположительно не более нескольких М.

В meminfo.c можно добавить поле Isolated(file), а также предполагаемый Clean.

Не 5, а НЕ БОЛЕЕ 1 МБ, судя по опытам, по крайней мере на моей машине.

Какая разница, если вычисление всё равно уходит в минус.

Если recl < dirty - явно имеется дефицит clean. Тогда почему б не сообщить, что clean=0?

Потому что:

• clean — не ресурс, у него нет дефицита по определению, вместо него есть не*бучая неопределённость касательно того, что в системе вообще происходит
• 0 может искусственно завысить жёсткий порог

Добавить-то можно, только атомарности всех показателей в целом от этого не добавится.

Ну так и положительный клин может быть ложноположительным. Показывает клин 10, а на самом деле там клин 100. По такой логике вообще нельзя никак оценивать клин.