Вы можете использовать open, read и write для прямого измерения скорости дискового ввода-вывода, избегая автоматической c потоковой буферизации (например, fopen).
Для read и write вы должны проверить прочитанные и записанные байты.
Для времени просто используйте clock_gettime(CLOCK_PROCESS_CPUTIME_ID,*tp) или CLOCK_THREAD_CPUTIME_ID (см. этот вопрос ). Я говорю это, потому что Linux включает в себя время ядра / системы от имени процесса (это явно для записи man для clock_gettime only в OpenBSD ). Возможно, вы захотите убедиться, что вы заполняете кеш диска и, возможно, кеш страницы диска ядра, если вы хотите измерить непрерывную (не пакетную) скорость. Таким образом, ваш вызов open будет возвращен только после завершения записи в файл.
Только использование описанного выше процесса даст вам результаты, которые вы получите при обычном использовании с использованием кэширования страниц диска ядра. Далее вы можете обойти кэширование страниц ядра следующим образом. Но имейте в виду, что это «необработанные» результаты и они не обязательно будут соответствовать результатам, когда вы используете кэширование страниц ядра, как описал Бэзил Старынкевич.
Вызов open с O_SYNC|O_DIRECT флаги режима работы (см. этот вопрос ). O_DIRECT обходит кеширование страниц ядра. Таким образом, ваши данные будут полностью переданы на диск и с диска, а не в кэш-память компьютера.
O_DIRECT (since Linux 2.4.10)
Try to minimize cache effects of the I/O to and from this
file. In general this will degrade performance, but it is
useful in special situations, such as when applications do
their own caching. File I/O is done directly to/from user-
space buffers. The O_DIRECT flag on its own makes an effort
to transfer data synchronously, but does not give the
guarantees of the O_SYNC flag that data and necessary metadata
are transferred. To guarantee synchronous I/O, O_SYNC must be
used in addition to O_DIRECT. See NOTES below for further
discussion.
Если я не ошибаюсь, вам не придется беспокоиться о планировании ядра другой процесс на вашем процессоре в тестировании, если большинство ваших процессоров не заняты. Даже если он запланирует другой процесс, он может вернуться к вашему процессу, как только синхронная запись будет завершена (пожалуйста, дайте мне знать в качестве комментария, если вы знаете). Поэтому использование CLOCK_MONOTONIC_RAW может не иметь значения. cpuset может быть полезно.
Обратитесь к Linux man записям и Справочному руководству библиотеки GNU C. Также см. fsync и в этом вопросе о том, сколько времени записи с кэшированием страницы занимает попадание на диск.