Если я вызову cat /dev/null два раза подряд для файла, будет ли второй вызов безуспешным?

Я хочу использовать cat filepath > /dev/null как дешевый механизм кэширования памяти. Меня интересует следующее: если я вызову его во второй раз, а файл уже будет в дисковом кеше, достаточно ли умна ОС, чтобы ничего не делать?

Обновление: я проверил это на томе CIFS, используя fadvise POSIX_FADV_WILLNEED для локального кэширования файла (используя linux-ftools в командной строке). Оказывается, чтобы это работало, том должен быть смонтирован в режиме чтения-записи. В режиме только для чтения причуда, кажется, игнорируется. Это должно иметь какое-то отношение к механизму oplock samba.


linux caching dev-null
person Jacko    schedule 22.05.2011    source источник
comment
Я думаю, вы имеете в виду cat filename > /dev/null?   -  person Rosh Oxymoron    schedule 22.05.2011
comment
Могу ли я увидеть пример того, что вы пытаетесь сделать, потому что я немного запутался в этом описании?   -  person Robert Massaioli    schedule 22.05.2011

Ответы (4)


arrow_upward
3
arrow_downward

Лучше posix_fadvise(...,POSIX_FADV_WILLNEED), чем катить файл в /dev/null - это требует меньше фактического ввода-вывода и не требует чтения содержимого файла в оперативной памяти пользовательского пространства, уничтожая кэши ЦП.

Более того, если соответствующая часть файла уже находится в кеше, posix_fadvise, вероятно, сделает гораздо меньше работы, чем файл cat > /dev/null

Если вы чувствуете, что вам действительно нужно, чтобы страницы были прямо сейчас в ядре, тогда mmap соответствующий раздел файла и mlock его (разблокируйте его позже; он может быть немедленно отброшен, если не хватает памяти) . Для этого нужны root-права.

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

person MarkR    schedule 22.05.2011
comment
Использование mlock() только для извлечения страниц в память немного сельскохозяйственно - во-первых, как вы указали, для этого требуется root. Вы можете добиться того же, просто прочитав один байт с каждой страницы в отображении или, что еще лучше, указав флаг MAP_POPULATE в mmap(). - person caf; 23.05.2011
comment
Да ладно, MAP_POPULATE делает это менее жестоко. Все равно не обязательно хорошая идея :) - person MarkR; 23.05.2011
comment
Спасибо, МаркР. Я попробую posix_fadvise. Будет ли это работать для файлов на монтировании CIFS в режиме только для чтения? - person Jacko; 23.05.2011
comment
Из справочных страниц Linux: POSIX_FADV_WILLNEED и POSIX_FADV_NOREUSE инициируют неблокирующее чтение указанной области в кэш страниц. Объем считываемых данных может быть уменьшен ядром в зависимости от загрузки ВМ. (Несколько мегабайт, как правило, будут полностью удовлетворены, а больше редко пригодится.). Так что это было бы идеально для меня, эти файлы весят около 100 КБ каждый. - person Jacko; 23.05.2011
comment
caf- не могли бы вы объяснить, как вы используете термин «сельскохозяйственный»? - person Jacko; 23.05.2011
comment
@Jacko: Я думаю, что это происходит от игры в крикет, где сельскохозяйственный удар - это дикий размахивающий удар, в котором очень мало техники или ловкости. - person caf; 24.05.2011

arrow_upward
3
arrow_downward

Нет, и не может.

Определить, будет ли программа ничего делать, обычно сложнее, чем просто запустить ее.

Зачем вообще нужно контролировать кэширование памяти? Если это абсолютно необходимо, рассмотрите возможность использования файловой системы tmpfs или использования compcache (сжатого блочного устройства RAM).

person BatchyX    schedule 22.05.2011
comment
Спасибо. Я хочу кэшировать файлы с монтирования CIFS, чтобы они были доступны в ОЗУ при следующем чтении. Но я не хочу отслеживать, был ли файл кэширован или нет. - person Jacko; 22.05.2011
comment
Для этого ядру нужен способ сообщить, что этот файл не был изменен с тех пор, как я последний раз читал его. Я не думаю, что CIFS позволяет серверу сообщать клиенту, что файл не был изменен (нет, время модификации не учитывается, так как это подделка). - person BatchyX; 23.05.2011
comment
Я думаю, что для CIFS существует блокировка уровня II. msdn.microsoft.com/en-us/library/aa302210.aspx - person Jacko; 24.05.2011

arrow_upward
2
arrow_downward

Это не будет ничего, как сказано в других ответах. Но если вы на самом деле имели в виду следующее:

Если я вызову его во второй раз, а файл уже находится в кеше диска, достаточно ли умна ОС, чтобы не читать его с диска во второй раз?

... тогда ответ да1. В конце концов, именно так работает дисковый кеш.

1. В любом случае, пока рассматриваемая файловая система использует кэш страниц.

person caf    schedule 23.05.2011
comment
Чтобы измерить разницу, кэш можно очистить, записав в /proc/sys/vm/drop_caches. См. proc(5). - person maxelost; 23.05.2011

arrow_upward
1
arrow_downward

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

person sehe    schedule 22.05.2011