Smart_Soft Jul 7 2014 at 13:54

Page-кэш, или как связаны между собой оперативная память и файлы

8 min

52K

Smart-Soft corporate blogProgramming*

Recovery Mode

Translation

+39

Comments 12

olegdunkan Jul 7 2014 at 15:56

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

am83 Jul 7 2014 at 16:02

Многие удивляются, но все стандартные операции файлового ввода / вывода работают через страничный кэш.

В общем случае это не совсем так. Читать или не читать из кеша решает конкретная файловая система. Например, есть ФС целиком размещаемые в памяти. Им держать файлы в кеше смысла нет.

iavael Jul 7 2014 at 23:33

tmpfs — это POSIX интерфейс к page cache-у. Данные хранятся именно в последнем.

amarao Jul 7 2014 at 16:04

Почему столько Windows? DLL файлы в Linux, постоянные отсылки в винды. Нафига?

lorc Jul 8 2014 at 18:10

Для сравнения. А в чем проблема?

kekekeks Jul 7 2014 at 16:45

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

-1

jcmvbkbc Jul 7 2014 at 17:42

процесс не имеет никакого контроля за тем, когда его выполнение прервётся для подкачки данных с диска

ровно так же, как и в случае использования выделенных буферов при наличии свопа. Ровно так же можно использовать mlock(all).

kekekeks Jul 7 2014 at 21:43

Оригинальное сообщение удалено.

Своп сам по себе убивает производительность, с этим ничего не сделать, только отключить его.

ToSHiC Jul 7 2014 at 17:52

Невозможность асинхронного ввода-вывода с использованием page-cache — это проблема исключительно реализации линукса, в других ОС это утверждение может быть ложным.

kekekeks Jul 7 2014 at 21:44

Текущий поток блокируется, пока не будет подгружена соответствующая страница. Это by-design, так как поток стопорится при попытке обращения к памяти.

ToSHiC Jul 8 2014 at 01:00

Вы определитесь, асинхронный ввод-вывод (AIO) или mmap :) Это, всё таки, разные интерфейсы.

valeriyvan Jul 8 2014 at 14:31

В Linux на x86-платформе, ядро представляет файл в виде последовательности 4-килобайтных фрагментов. Если запросить прочтение всего навсего одного байта из файла, то этого приведет к тому, что 4-килобайтный фрагмент, содержащий данный байт, будет целиком прочитан с диска и помещен в страничный кэш. Вообще говоря, в этом есть смысл, потому что, во-первых, производительность при непрерывном чтении с диска (sustained disk throughput) является достаточно высокой, и, во-вторых, программы обычно читают более одного байта из некоторой области файла.

Так сделано не для того, чтоб ускорить чтение а потому что иначе сделать невозможно. С жесткого диска нельзя прочитать один байт. С диска можно прочитать только сектор(кластер) целиком. Аналогично и с записью. Поэтому операционная система, предоставляющая возможность читать файл побайтово, вынуждена читать с диска сектор(кластер) целиком а потом отдавать нужные байты по одному. При записи одного единственного байта в файл система прочитает нужный сектор(кластер), заменит нужный байт и запишет сектор(кластер) назад в файл. Такого рода механизмы были даже в MS-DOS, потому что так устроены интерфейсы жестких дисков.