Спустя 7 месяцев после предыдущего релиза вышел cache-bench 0.2.0. Cache-bench - это Python скрипт, позволяющий оценить влияние настроек виртуальной памяти (vm.swappiness, vm.watermark_scale_factor, Multigenerational LRU Framework и прочих) на производительность задач, выполнение которых зависит от кэширования файловых операций чтения, особенно в условиях нехватки памяти. Код открыт под лицензией CC0...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56376

• Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,Аноним, 12:24 , 19-Дек-21
  • Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,Аноним, 13:35 , 19-Дек-21
    • Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,foo, 14:33 , 19-Дек-21
• Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,pavlinux, 15:22 , 20-Дек-21
  • Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,foo, 15:41 , 20-Дек-21
    • Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,pavlinux, 15:49 , 20-Дек-21
  • Выпуск cache-bench 0.2.0 для исследования эффективности кэши...,Ordu, 14:17 , 21-Дек-21

>Теперь вместо чтения файлов из указанной директории (в новой версии опция -d удалена) производится чтение из одного файла фрагментами указанного размера в случайном порядке.

Так это же ухудшение.

Непонятное "улучшение". Размер файла теперь должен быть как минимум сопоставим с размером файлового кеша. Иначе скэшируется он полностью и что там потом бенчить - память? Файлов в гигабайты с лету не найду - разве что образы дисков.

>Размер файла теперь должен быть как минимум сопоставим с размером файлового кеша. Иначе скэшируется он полностью и что там потом бенчить - память?

Для этогои писался изначально - исследовать влияние факторов на сохранность кэша при нехватке памяти. Оригинальный основной режим - это читать из небольшого файла (100-300 МБ, сопоставимого по размеру с обычным размером кэша разделяемых библиотек) и добавлять прочитанное в список, таким образом создавая в итоге нехватку памяти.

И что с этим делать? Опять руками дроч...^W настраивать sysctl vm.*?

21 век уж как 21 год, ...
$ sysctl -A | grep vm. | wc -l
45

~ 45 параметров, основная масса из них с одним аргументом, половину выкинуть можно,
типа vm.mmap_min_addr,  vm.panic_on_oom, vm.mmap_rnd_bits, vm.laptop_mode, vm.legacy_va_layout, ...

Ну ебнвр, вставляйте в ваши хелловорлды анализ и автотюнинг на его базе со сравнением результатов.

for ((i=0; i<A; i++)
   for ((j=0; j<A; j++)
      for ((k=0; k<A; k++)
         for ((l=0; l<A; l++)
                       ...

                       ...

Да, тут мозг нужен, а не тупа R/W с секундомером измерить.

>тут мозг нужен

Интегрировать скрипт с нейросетью?

>>тут мозг нужен
> Интегрировать скрипт с нейросетью?

Что за мода, называть всё что сложнее if ( a > b ) - нейросетью? )))

Обычная комбинаторика, нет там нейросвязей.

...
for (.....)

   set_sysctl_next(i);

   test = mega_bruteforce_bench(i);

   if (test > best)
        save_sysctl_param(i);

   best = max(best, test)

...

Там даже проблема не в переборе и сравнении, сколько в адекватности результатов
выдваваемых mega_bruteforce_bench(i);  Нужно быть на 146% уверенным, что изменение
в sysctl влияет на этот тест.

А то ж можно факториал 45 раз воздух обогревать.
Автор вон, дрочит vm.swappiness, а в реальности окажется что fs.file-nr кривой,
или неправильно понят fs.xfs.rotorstep, иль из гугла скопипастили параметр монтирования barrier=1  

> for ((i=0; i<A; i++)
>   for ((j=0; j<A; j++)
>      for ((k=0; k<A; k++)
>         for ((l=0; l<A; l++)

Это хрень какая-то. Напрашивается жеж принять допущение монотонности, и дальше градиентным спуском. В смысле замеряешь градиент, двигаешься в ту сторону, замеряешь ещё раз, и тп. Вектор из 45 элементов -- это много, конечно, но какая собственно разница, если компьютер будет пыхтеть мерять?

> Да, тут мозг нужен

В том-то и дело. Брутфорсом против комбинаторики далеко не уедешь.