Спустя 7 месяцев после предыдущего релиза состоялся релиз cache-bench 0.2.0.

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

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

Добавлены опции:

• --file – путь к файлу, из которого будет производиться чтение;
• --chunk – размер фрагмента в кибибайтах, по умолчанию 64;
• --mmap – читать из memory-mapped файлового объекта вместо чтения из файлового дескриптора;
• --preread – перед началом теста предварительно прочитать (кэшировать) указанный файл путем последовательного чтения фрагментами размером 1 МиБ;
• --bloat – добавлять считываемые фрагменты в список с целью увеличения потребления памяти процессом и создания в дальнейшем нехватки памяти;
• --interval – интервал вывода (логирования) результатов в секундах.

Примеры использования можете найти на странице проекта.

>>> Подробности

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

Основной способ использования - считывание файлов из указанной директории в случайном порядке и их добавление в список, пока не будет считано заданное число мебибайт.

Имеет два режима работы. Первый - вспомогательный - служит для создания директории заданного объема. При этом в директории создается заданное число мебибайтных файлов со случайными именами.

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

Частью проекта также является вспомогательных скрипт drop-cache, который рекомендуется выполнять перед началом теста.

В процессе работы скрипта в режиме чтения выводится общее время работы, средняя скорость чтения, имя последнего считанного файла.

Скрипт также позволяет логировать результаты в файл. Пример лога:

2021-05-30 21:47:56,084: mkdir testdir1
2021-05-30 21:47:56,211: written testdir1/0.9860985015646311; total size: 1M
2021-05-30 21:47:56,289: written testdir1/0.0691916965192153; total size: 2M
2021-05-30 21:47:56,377: written testdir1/0.27868153831296383; total size: 3M
2021-05-30 21:47:56,455: written testdir1/0.7341114648416274; total size: 4M
2021-05-30 21:47:56,533: written testdir1/0.5363495159203434; total size: 5M
2021-05-30 21:47:56,533: OK
2021-05-30 21:48:23,193: found 5 regular files in testdir1, total size: 5.0M
2021-05-30 21:48:23,199: setting self oom_score_adj=1000
2021-05-30 21:48:23,199: reading files from the directory testdir1
2021-05-30 21:48:23,229: read 1.0M (20.0%) in 0.0s (avg 32.9M/s); file 0.7341114648416274
2021-05-30 21:48:23,296: read 2.0M (40.0%) in 0.1s (avg 20.8M/s); file 0.0691916965192153
2021-05-30 21:48:23,298: read 3.0M (60.0%) in 0.1s (avg 30.3M/s); file 0.0691916965192153
2021-05-30 21:48:23,299: read 4.0M (80.0%) in 0.1s (avg 40.1M/s); file 0.7341114648416274
2021-05-30 21:48:23,352: read 5.0M (100.0%) in 0.2s (avg 32.6M/s); file 0.27868153831296383
2021-05-30 21:48:23,353: --
2021-05-30 21:48:23,353: read 5.0M in 0.2s (avg 32.6M/s); src: 5 files, 5.0M
2021-05-30 21:48:23,354: OK

>>> Подробности

Один из членов команды разработки социальной сети Facebook, Роман Гущин, предложил в рассылке разработчиков набор из патчей для ядра Linux, направленных на улучшение работы с памятью через реализацию нового контроллера управления оной – slab (slab memory сontroller).

Распределение slab – это механизм управления памятью, предназначенный для более эффективного распределения памяти и устранения значительной фрагментации. Основой этого алгоритма является сохранение выделенной памяти, содержащей объект определенного типа, и повторное использование этой памяти при следующем выделении для объекта того же типа. Этот метод был впервые введен в SunOS Джефом Бонвиком и сейчас широко используется в ядрах многих операционных систем Unix, включая FreeBSD и Linux.

В основе нового контроллера лежит перенос учёта slab с уровня страниц памяти на уровень объектов ядра, что предоставляет возможность совместного использования одной slab-страницы в разных cgroup, вместо выделения отдельного кэша для каждой cgroup.

По результатам испытаний следует, что предложенный метод управления памятью позволяет повысить эффективность использования slab до 45%, а также понизит общее потребление памяти ядром ОС. Также за счет сокращения количества выделяемых под slab страниц уменьшается фрагментация памяти в целом, что не может не сказаться на быстродействии системы.

Новый контроллер уже несколько месяцев тестируется на рабочих серверах Facebook, и пока это тестирование можно назвать успешным: при отсутствии потерь в быстродействии и увеличения количества ошибок замечено явное уменьшение расхода памяти – на некоторых серверах до 1Гб. Это число довольно субъективно, так, например, ранее проведенные тесты показали немного меньшие результаты:

• 650-700 МБ на веб-фронтенде;
• 750-800 МБ на сервере с кэшем баз данных;
• 700 МБ на DNS-сервере.

>>> Страничка автора на GitHub

>>> Результаты ранних тестов

>>> Подробности

Группа исследователей из нескольких университетов обнаружила новые варианты эксплуатации уязвимости Rowhammer в подсистеме ION (драйвер памяти) являющейся частью ОС Android, используемом в Android-устройствах начиная с версии 4.0 «Ice Cream Sandwich» (устройства. выпущенные с 2012 года).

RAMpage схожа с уже известной атакой DRammer, воздействующей на аппаратную уязвимость Rowhammer и заключается в вынужденном переключении состояния ячеек DRAM — из-за высокой плотности компоновки ячеек становится возможно спровоцировать переключение соседних ячеек постоянной перезаписью памяти, доступной атакующему процессу. Атака RAMpage r0 заставляет ION путем исчерпания области highmem размещать страницы памяти непрерывно и поместить страницу памяти атакующего приложения в область lowmem, где после может быть расположена таблица страниц ядра. На этом этапе осуществляется поиск уязвимых к bit flip областей и после этого память освобождается обратно, что косвенным образом заставляет ION поместить системную память на уязвимую область физической памяти, где и осуществляется атака. По мнению специалистов проведение атаки возможно выполнить на большинстве современных устройств с памятью LPDDR2, LPDDR3 и LPDDR4.

Для снижения риска эксплуатации был опубликован инструмент GuardION, суть которого заключается в добавлении промежутков в памяти между страницами, не позволяющими исполнить такой вариант атаки.

PDF с описанием атаки и описанием механизма работы GuardION

>>> Подробности