Есть ли смысл в буферизации чтения\запись на стороне прикладного ПО

man mmap

Вааау. Шикарная штука, взял на вооружение!
Тогда про линупсы перефразирую: что выгоднее, mmap или буферизация в плане производительности IO.
Но вот на оффтопике такого вызова нет. (а вдруг надо будет поддерживать)

UPD: и под офтопиком есть, просто по-другому зовется.

Нашел ответ на свои вопросы: http://habrahabr.ru/post/55716/
Спасибо, а то занимался бы сейчас извращениями с буфферизацией

это зависит от ситуации.

mmap это очень легко, но очень непредсказуемо.

Мы в эрливидео отказались от mmap, потому что он не дает выйти на нужный перфоманс из-за непредсказуемых залипаний на диске.

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

ну, например:
http://xmodulo.com/how-to-enable-local-file-caching-for-nfs-share-on-linux.html
не оно?
хотя NFS на то и NFS, что файлы хрен знает откуда подтягиваются и, вообще говоря, могут изменяться. так что кеширование в чистом виде тут работать по-любому будет непредсказуемо.

из-за непредсказуемых залипаний на диске

Можно поподробней? В чём конкретно заключается «непредсказуемость» и что значит «залипаний»?

В одном проекте воткнули самопальный костыль для буферизации записи по 2 мегабайта и получили 40-кратный прирост скорости записи, потому что так настроен NFS и не перенастроить.

Скорее всего проблемы была во врайтах на пару байт.

Вообще без буферизации это как? На каждый байт дёргать сисколл read/write?

Всё IO и так буферизиурется если не принимать специальных мер, разница будет примерно в накладных расходах на сисколы и может быть в каких-нибудь оптимизациях с read ahead'ом.

Можно помогать механизму кеширования хинтами используя ф-ии {posix_,}madvise(...), posix_fadvise(...), {posix_,}fallocatе(...) и readahead(...) или даже явно держать в памяти некоторые участки (индексы, например) через mlock(..) зная особенности патеррнов доступа к данным своей программы. Стандартая логика кеширования достаточно топорная, потому для нетривиальных паттернов можно повысить эффективность IO через хинты и ручное кеширование.

на сервере 20 дисков с которых раздаются сериалы. Народ смотрит как не в себя.

Если читаем с диска через read, то каждый read в отдельном треде (пул тредов) и если один из хардов перегрузился по чтению, то остальные будут отвечать и программа просто будет на 5% медленнее работать.

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

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

Линейно или случайно? В первом случае не парься и читай оптимальными для ФС блоками, во втором попроси Page Cache уменьшить дистанцию RA.

И так и так, в зависимости от режима.
Можно поподробнее про второй?

man posix_madvise

Уже, я не совсем понял что имеется в виду под «дистанцией RA»

read ahead

Спасибо, великий Аноним.