Определение пропусков кэша для различных файловых систем

Question

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

1. Создайте программу, которая заработает файловую систему и заполнит буферный кеш.
2. Используйте средство сравнения систем для записи количества промахов в кеше.
3. Промыть и повторить с новыми условиями.

Но, будучи новичком в разработке операционной системы, я не уверен, как действовать дальше. Итак, вот некоторые моменты, в которых мне нужно: help:

1. Какие действия будет выполнять идеальная программа для заполнения буферного кеша? В настоящее время программа, которую я написал, читает и записывает в несколько разных файлов, х раз.
2. Какие инструменты записывают количество промахов в кеше? Я просмотрел oprofile, но я не думаю, что он контролирует буферный кэш файловой системы. Но я нашел это list, который выглядит многообещающим.
3. Будут ли другие запущенные процессы влиять на эти тесты?

Благодарим за помощь!

Answer 1

1) Если вы пытаетесь протестировать производительность своей файловой системы, бросьте несколько потоков, которые манипулируют большими количествами метаданных файла вместе с вашими потоками ввода-вывода. Кроме того, при выполнении операций ввода-вывода в нескольких параллельных потоках смешайте потоки с крупномасштабными передачами и потоками, выполняющими небольшие перемещения. Многие файловые системы объединит небольшие операции ввода-вывода вместе в более крупные запросы, которые физический диск может обрабатывать более эффективным с точки зрения времени образом, а смешение ввода-вывода различного размера может помочь быстрее увеличить кеш (поскольку он должен буферизовать объединенные I/O).

2) Будьте осторожны с этим списком инструментов, многие из них выглядят так, как будто они предназначены для работы с необработанными устройствами, а не через уровень файловой системы (поэтому полученные вами результаты могут не представлять того, что вы думаете, что они делают). Если вы ищете инструмент для тестирования конкретной файловой системы, лучшим вариантом может быть проверка с командой разработчиков этой файловой системы. Они, скорее всего, укажут вам на инструмент, который они использовали для оценки своих FS во время разработки, даже если это настраиваемый инструмент, разработанный внутри страны.

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

Answer 2

Это интересный вопрос. Может быть, я могу дать вам частичный ответ.

Вы должны знать, что Linux имеет несколько кэшей, связанные с файловыми системами, которые могут иметь различные инструменты

кэш

• Inode
• Dentry кэш
• кэш Блок

Одним из способов является вычислить (угадать?), сколько трафика на уровне блоков ваши операции должны генерировать, а затем измерять операции реального блока (чтение, запись, поиск) с помощью blktrace.

Мне неизвестен какой-либо способ прочитать состояние промаха кэша в контейнере inode и dentry. Мне бы очень хотелось, чтобы мне сказали, что я здесь неправ.

Трудный способ состоит в том, чтобы аннотировать кэш inode и кэш-память dentry с собственными счетчиками, но эти кэши представляют собой довольно жесткий код ядра.