LINUX.ORG.RU
ФорумTalks

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

 , , ,


4

3

Во-первых, вышла новая линейка для этой самой защиты: https://github.com/hakavlad/le9-patch/tree/main/le9db_patches.

В описании патчей все написано.

Спрашивайте ответы, если еще остались вопросы.

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

hakavlad ★★★ ()
Ответ на: комментарий от Spoofing

Еще вариант:

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

hakavlad ★★★ ()

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

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

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

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

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

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

hakavlad ★★★ ()
Ответ на: какое отношение к 12309? от n_play

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

hakavlad ★★★ ()
Ответ на: комментарий от hakavlad

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

t184256 ★★★★★ ()

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

DawnCaster ★★ ()
Последнее исправление: DawnCaster (всего исправлений: 1)
Ответ на: комментарий от post-factum

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

Может:

[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
post-factum ★★★★★ ()
Ответ на: комментарий от hakavlad

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

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

luke ★★★★★ ()
Ответ на: комментарий от post-factum
  •  	clean_file = ULONG_MAX;
    

Почему не 0?

  •  if (unlikely(
    

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

hakavlad ★★★ ()
Ответ на: комментарий от post-factum

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

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

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

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

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

hakavlad ★★★ ()
Ответ на: комментарий от hakavlad

Почему не 0?

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

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

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

post-factum ★★★★★ ()

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

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от post-factum

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

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

hakavlad ★★★ ()
Ответ на: комментарий от hakavlad

Почему не 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; 

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

hakavlad ★★★ ()
Ответ на: комментарий от post-factum

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

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

hakavlad ★★★ ()
Ответ на: комментарий от hakavlad

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

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

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

hakavlad ★★★ ()
Ответ на: комментарий от post-factum

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

hakavlad ★★★ ()
Ответ на: комментарий от hakavlad

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

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

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

Потому что:

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

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

hakavlad ★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)