Что такое dirty pages
Демон pdflush
Измененные (dirty, «грязные») страницы памяти когда-нибудь должны быть записаны на диск. Обратная запись страниц памяти выполняется в следующих двух случаях.
• Когда объем свободной памяти становится меньше определенного порога, ядро должно записать измененные данные обратно на диск, чтобы освободить память.
• Когда несохраненные данные хранятся в памяти достаточно долго, то ядро должно их записать на диск, чтобы гарантировать, что эти данные не будут находиться в несохраненном состоянии неопределенное время.
Эти два типа записи имеют разные цели. В более старых ядрах они выполнялись двумя разными потоками пространства ядра (см. следующий раздел). Однако в ядре 2.6 эту работу выполняет группа (gang[87]) потоков ядра pdflush, которые называются демонами фоновой обратной записи (или просто потоками pdflush). Ходят слухи, что название pdflush — это сокращение от «dirty page flush» («очистка грязных страниц»). Не обращайте внимание на это сомнительное название, давайте лучше более детально рассмотрим, для чего нужны эти процессы.
Во-первых, потоки pdflush служат для записи измененных страниц на диск, когда объем свободной памяти в системе уменьшается до определенного уровня. Цель такой фоновой записи — освобождение памяти, которую занимают незаписанные страницы, в случае недостатка физических страниц памяти. Уровень, когда начинается обратная запись, может быть сконфигурирован с помощью параметра dirty_background_ratio утилиты sysctl. Когда объем свободной памяти становится меньше этого порога, ядро вызывает функцию wakeup_bdflush()[88] для перевода в состояние выполнения потока pdflush, который выполняет функцию обратной записи измененных страниц памяти background_writeout(). Эта функция получает один параметр, равный количеству страниц, которые функция должна попытаться записать на диск.
Функция продолжает запись до тех пор, пока не выполнятся два следующих условия.
• Указанное минимальное количество страниц записано на диск.
• Объем свободной памяти превышает соответствующее значение параметра dirty_background_ratio.
Выполнение этих условий гарантирует, что демон pdflush выполнил свою работу по предотвращению нехватки памяти. Если эти условия не выполняются, то обратная запись может остановиться только тогда, когда демон pdflush запишет на диск все несохраненные страницы и для него больше не будет работы.
Во-вторых, назначение демона pdflush — периодически переходить в состояние выполнения (независимо от состояния нехватки памяти) и записывать на диск очень давно измененные страницы памяти. Это гарантирует, что измененные страницы не будут находиться в памяти неопределенное время. При сбоях системы будут потеряны те страницы памяти, которые не были сохранены на диске, так как содержимое памяти после перегрузки не сохраняется. Следовательно, периодическая синхронизация страничного кэша с данными на диске является важным делом. При загрузке системы инициализируется таймер, периодически возвращающий к выполнению поток pdflush, который выполняет функцию wb_kupdate(). Эта функция выполняет обратную запись данных, которые были изменены более чем dirty_expire_centisecs сотых секунды тому назад. После этого таймер снова инициализируется, чтобы сработать через dirty_expire_centisecs сотых секунды. Таким образом потоки pdflush периодически возвращаются к выполнению и записывают на диск все измененные страницы, данные в которых старше, чем указанный лимит.
Системный администратор может установить эти значения с помощью каталога /proc/sys/vm и утилиты sysctl. В табл. 15.1 приведен список всех соответствующих переменных.
Таблица 15.1. Параметры для настройки демона pdflush
Переменная Описание dirty_background_ratio Объем свободной оперативной памяти, при котором демон pdflush начинает обратную запись незаписанных данных dirty_expire_centisecs Время, в сотых долях секунды, в течение которого незаписанные данные могут оставаться в памяти, перед тем как демон pdflush не запишет их на диск при следующем периоде обратной записи dirty_ratio Процент от общей оперативной памяти, соответствующий страницам памяти одного процесса, при котором начинается обратная запись незаписанных данных dirty_writeback_centisecs Насколько часто, в сотых долях секунды, процесс bdflush возвращается к выполнению для обратной записи данных laptop_mode Переменная булевого типа, которая включает или выключает режим ноутбука (см. следующий раздел)
Код потока pdflush находится в файлах mm/page-writeback.c и fs/fs-writeback.c.
Режим ноутбука — это специальная политика обратной записи страниц с целью оптимизации использования батареи и продления срока ее работы. Это делается путем минимизации активности жестких дисков, чтобы они оставались в остановленном состоянии по возможности долго. Конфигурировать этот режим можно с помощью файла /proc/sys/vm/laptop_mode. По умолчанию в этом файле записано значение 0 и режим ноутбука выключен. Запись значения 1 в этот файл позволяет включить режим ноутбука.
В режиме ноутбука существует всего одно изменение в выполнении обратной записи страниц. В дополнение к обратной записи измененных страниц; памяти, когда они становятся достаточно старыми, демон pdflush также выполняет и все остальные операции дискового ввода-вывода, записывая все дисковые буферы на диск. Таким образом демон pdflush пользуется тем преимуществом, что диск уже запущен, а также он гарантирует, что в ближайшем будущем диск снова запущен не будет.
Такое поведение имеет смысл, когда параметры dirty_expire_centisecs и dirty_writeback_centisecs установлены в большие значения, скажем 10 минут. При таких задержках обратной записи диск запускается не часто, а когда он все-таки запускается, то работа в режиме ноутбука гарантирует, что этот момент будет использован с максимальной эффективностью.
Во многих поставках ОС Linux режим ноутбука автоматически включается и выключается, при этом также могут изменяться и другие параметры демона pbflush, когда заряд батареи уменьшается. Такое поведение позволяет получать преимущества от режима ноутбука при работе от батареи и автоматически возвращаться к нормальному поведению, когда машина включается в электрическую сеть.
Читайте также
Демон ksoftirqd
Демон ksoftirqd Обработка отложенных прерываний (softirq) и, соответственно, тасклетов может осуществляться с помощью набора потоков пространства ядра (по одному потоку на каждый процессор). Потоки пространства ядра помогают обрабатывать отложенные прерывания, когда система
Демон
Демон Демоны играют важную роль в работе операционной системы. Достаточно будет сказать, что возможность терминального входа пользователей в систему, доступ по сети, использование системы печати и электронной почты, — все это обеспечивается соответствующими демонами
13.2. Демон syslogd
13.2. Демон syslogd Системы Unix обычно запускают демон syslogd в одном из сценариев инициализации системы, и он функционирует, пока система работает. Реализации syslogd, происходящие от Беркли, выполняют при запуске следующие действия:1. Считывается файл конфигурации, обычно /etc/syslog.conf,
13.5. Демон inetd
13.5. Демон inetd В типичной системе Unix может существовать много серверов, ожидающих запроса клиента. Примерами являются FTP, Telnet, Rlogin, TFTP и т.д. В системах, предшествующих 4.3BSD, каждая из этих служб имела связанный с ней процесс. Этот процесс запускался во время загрузки из файла
28.7. Демон сообщений ICMP
28.7. Демон сообщений ICMP Получение асинхронных ошибок ICMP на сокет UDP всегда было и продолжает оставаться проблемой. Ядро получает сообщения об ошибках ICMP, но они редко доставляются приложениям, которым необходимо о них знать. Мы видели, что для получения этих ошибок в API
Демон icmpd
Демон icmpd Начинаем описание нашего демона icmpd с заголовочного файла icmpd.h, приведенного в листинге 28.23.Листинг 28.23. Заголовочный файл icmpd.h для демона icmpd//icmpd/icmpd.h 1 #include «unpicmpd.h» 2 struct client < 3 int connfd; /* потоковый доменный сокет Unix к клиенту */ 4 int family; /* AF_INET или AF_INET6 */ 5 int lport; /*
5.4. Демон inetd/xinetd
5.4. Демон inetd/xinetd Для того чтобы сервер смог обрабатывать запросы клиентов, программа должна быть постоянно загружена и связана с определенным портом. В этом нет ничего сложного, но зачем постоянно держать программу в памяти, особенно если она слишком большая, а работает
5.8.5. Демон klogd
9.4.2. Диспетчер расписаний — демон cron
9.4.2. Диспетчер расписаний — демон cron Этот демон запускается во время инициализации системы (сценарий /etc/init.d/crond), читает свои конфигурационные файлы и переходит в режим ожидания. Раз в минуту демон просыпается, проверяет дату последнего изменения конфигурационных файлов,
19.2.1. Демон routed
19.2.1. Демон routed Стандартной программой маршрутизации в Linux является демон routed. Этот демон, как правило, настраивается сам (динамически) и не требует конфигурирования. Обнаруженные маршруты он заносит в маршрутную таблицу ядра.В своей работе демон routed использует протокол
19.2.2. Демон gated — правильный выбор
19.2.2. Демон gated — правильный выбор В последнее время демон gated используется чаще, чем стандартный routed. Объясняется это тем, что gated более гибок в конфигурировании и обладает большими возможностями, в частности, им поддерживаются протоколы RIP-2 и OSFP.Программа gated была
11.6.8.2. Пара спулер/демон
11.6.8.2. Пара спулер/демон Облегченный вариант пары конфигуратор/актор может оказаться полезным в ситуациях, когда требуется сериализованный доступ к общему ресурсу в пакетном режиме, т.е. когда четко определенный поток заданий или последовательность запросов требует
11.6.8.2. Пара спулер/демон
11.6.8.2. Пара спулер/демон Облегченный вариант пары конфигуратор/актор может оказаться полезным в ситуациях, когда требуется сериализованный доступ к общему ресурсу в пакетном режиме, т.е. когда четко определенный поток заданий или последовательность запросов требует
Пердем – персональный демон
Пердем – персональный демон LinuxFormat #112 (декабрь 2008)Все знают, что пермаш – это персональная машина, пердач – персональная дача, перпен – это. нет, не то, что вы подумали, а персональная пенсия, и так далее. А вот что такое пердем? Это – персональный демон, система PC-BSD,
Оптимизация Linux под нагрузку. Кэширование операций записи на диск.
Недавно на одном из виртуальных серверов столкнулся с проблемой долгой записи на диск. И под эту тему нашел интересную статью, в которой подробно рассмотрен вопрос функционирования кэширования операций записи на диск в Linux. Сегодня будет перевод этой статьи.
Кэширование в Linux
При записи данных на диск (любой программой) Linux кэширует эту информацию в области памяти, называемой Page Cache (страничный кэш). Информацию об этой области памяти можно посмотреть с помощью команд free, vmstat или top. Полную информацию об этой области памяти можно посмотреть в файле /proc/meminfo. Ниже приведен пример этой файла на сервере с 4-мя GB RAM:
Размер Page Cache показан в параметре «Cached», в данном примере он составляет 2,9 GB. При записи страниц в память размер параметра «Dirty» увеличивается. При начале непосредственно записи на диск будет увеличиваться параметр «Writeback» до тех пор, пока запись не закончится. Достаточно сложно увидеть параметр «Writeback» высоким, так как его значение увеличивается только во время опроса, когда операции ввода/вывода (I/O) поставлены в очередь, но еще не записаны на диск.
Linux обычно записывает данные из кэша на диск с помощью процесса pdflush. В любой момент в системе запущено от 2 до 8 потоков pdflush. В файле /proc/sys/vm/nr_pdflush_threads можно посмотреть сколько в данный момент активных потоков. Каждый раз все существующие потоки pdflush заняты по крайней мере 1 секунду. Новые потоки пытаются записать данные в свободные очереди устройств, таким образом, чтобы на каждое активное устройство был 1 поток сбрасывающий данные из кэша. Каждый раз по прошествии секунды без какой либо активности со стороны pdflush убирается 1 поток. В Linux можно настроить минимальное и максимальное количество pdflush потоков.
Настройка pdflush
Каждый поток pdflush контролируется несколькими параметрами в /proc/sys/vm:
Итого: Когда pdflush начинает запись?
В конфигурации по умолчанию, данные, записываемые на диск, находятся в памяти до тех пор пока:
Если на сервере операции записи происходят часто, то однажды будет достигнут параметр dirty_background_ratio, и вы сможете увидеть, что вся запись на диск идет только через этот параметр не дожидаясь истечения параметра dirty_expire_centiseconds.
Процесс записи страниц
Параметр /proc/sys/vm/dirty_ratio (default 40): Максимальный процент общей оперативной памяти, который может быть выделен под страничный кэш, до того как pdflush будет писать данные на диск.
Примечание: Во время записи на диск все процессы блокируются на запись, не только тот который заполнил буфер на запись. Это может вызвать спровоцировать блокировку одним процессов всех операций вводы/вывода в системе. Провести этот
Рекомендации по оптимизации Linux для операций, требующий частой записи
Обычно люди при попытке увеличения производительности дисковой подсистемы сталкиваются с проблемой, что Linux буферизует слишком много информации сразу. Это особенно трудно для операций, требующий синхронизации файловой системы, использующих вызовы fsync. Если во время такого вызова в кэше много данных, то система может «подвиснуть» пока не закончится этот вызов.
Другая частая проблема происходит потому что слишком много требуется записать до того, как начнется запись на физический диск, операции ввода/вывода происходят чаще, чем при нормальной работе. Вы получите более долгие периоды, когда запись на диск не происходит, пока большой кэш не будет заполнен, после чего сработает один из триггеров pdflush и данные запишутся на максимальной скорости.
dirty_background_ratio: Основной инструмент настройки, обычно уменьшают этот параметр. Если ваша цель снизить количество данных, хранимое в кэше, так что данные будут писаться на диск постепенно, а не все сразу, то уменьшение этого параметра наиболее эффективный путь. Более приемлемо значение по умолчанию для систем имеющих много оперативной памяти и медленные диски.
dirty_ratio: Второй по значимости параметр для настройки. При значительном снижении этого параметра приложения, которые должны писать на диск, будут блокироваться все вместе.
dirty_expire_centisecs: Попробуйте уменьшить, но не сильно. Позволяет уменьшить время нахождения страниц в кэше до записи на диск, но это значительно снизит среднюю скорость записи на диск, т.к. это менее эффективно. Это особенно проявится на системах с медленными дисками.
Инструкция по настройке параметров
В файле /etc/sysctl.conf вносим, например:
После синхронизируем данные кэша и диска, очистим кэш и сохраним параметры.
Page-кэш, или как связаны между собой оперативная память и файлы
Ранее мы познакомились с тем, как ядро управляет виртуальной памятью процесса, однако работу с файлами и ввод/вывод мы опустили. В этой статье рассмотрим важный и часто вызывающий заблуждения вопрос о том, какая существует связь между оперативной памятью и файловыми операциями, и как она влияет на производительность системы.
Что касается работы с файлами, тут операционная система должна решить две важные проблемы. Первая проблема – удивительно низкая скорость работы жестих дисков (особенно операций поиска) по сравнению со скоростью оперативной памяти. Вторая проблема – возможность совместного использования единожды загруженного в оперативную память файла разными программами. Взглянув на процессы с помощью Process Explorer, мы увидим, что порядка 15 МБ оперативной памяти в каждом процессе тратится на общие DLL-библиотеки. На моем компьютере в данный момент выполняется 100 процессов, и, если бы не существовала возможность совместного использования файлов в памяти, то около 1,5 ГБ памяти тратилось бы только на общие DLL-библиотеки. Это, конечно, неприемлемо. В Linux, программы тоже используют разделяемые библиотеки типа ld.so, libc и других.
К счастью, обе проблемы можно решить, как говорится, одним махом – с помощью страничного кэша (page cache). Страничный кэш используется ядром для хранения фрагментов файлов, причем каждый фрагмент имеет размер в одну страницу. Для того, чтобы лучше проиллюстрировать идею страничного кэша, я придумал программу под названием render, которая открывает файл scene.dat, читает его порциями по 512 байт и копирует их в выделенное пространство в куче. Первая операция чтения будет осуществлена так, как показано на рисунке вверху.
После того, как будут прочитаны 12 KБ, куча процесса render и имеющие отношения к делу физические страницы будут выглядеть следующим образом:
Кажется, все просто, но на деле все, много чего происходит. Во-первых, даже несмотря на то, что наша программа использует обычные вызовы read(), в результате их выполнения в страничном кэше окажется три 4-килобайтных страницы с содержимым файла scene.dat. Многие удивляются, но все стандартные операции файлового ввода / вывода работают через страничный кэш. В Linux на x86-платформе, ядро представляет файл в виде последовательности 4-килобайтных фрагментов. Если запросить прочтение всего навсего одного байта из файла, то этого приведет к тому, что 4-килобайтный фрагмент, содержащий данный байт, будет целиком прочитан с диска и помещен в страничный кэш. Вообще говоря, в этом есть смысл, потому что, во-первых, производительность при непрерывном чтении с диска (sustained disk throughput) является достаточно высокой, и, во-вторых, программы обычно читают более одного байта из некоторой области файла. Страничный кэш знает о том, какое место в файле занимает каждый скэшированный его фрагмент; это изображено на рисунке как #0, #1, и т.д. В Windows используются 256-килобайтные фрагменты (называемые “view”), которые по своему предназначению аналогичны страницам в страничном кэше Linux.
При использовании обычных операций чтения, данные сначала попадают в страничный кэш. Программисту данные доступны порционально, через буфер, и из него он копирует их (в нашем примере) в область в куче. Данный подход к делу является крайне неэффективным – не только тратятся вычислительные ресурсы процессора и оказывается негативное влияние на процессорные кэши, но также происходит напрасная трата оперативной памяти на хранение копий одних и тех же данных. Если взглянуть на предыдущий рисунок, то будет видно, что содержимое файла scene.dat хранится сразу в двух экземплярах; любой новый процесс, работающий с этим файлом, скопирует эти данные еще раз. Таким образом, вот чего мы добились – несколько уменьшили проблему задержки при чтении с диска, но в остальном потерпели полную неудачу. Однако, решение проблемы существует – это «отображение файлов в память» (memory-mapped files):
Когда программист использует отображение файлов в память, ядро мэппирует виртуальные страницы напрямую в физические страницы в страничном кэше. Это позволяет добиться значительного прироста производительности – в Windows System Programming пишут об ускорении времени выполнения программы на 30% и более по сравнению со стандартными файловыми операциями ввода/вывода. Аналогичные цифры, только теперь уже для Linux и Solaris, приводятся и в книге Advanced Programming in the Unix Environment. С помощью данного механизма можно писать программы, которые будут использовать значительно меньше оперативной памяти (хотя тут многое также зависит от особенностей самой программы).
Как всегда, главное в вопросах производительности – это измерения и наглядные результаты. Но даже и без этого, отображение файлов в память вполне себя окупает. Интерфейс программирования – достаточно приятный и позволяет читать файлы как обычные байты в памяти. Ради всех преимуществ данного механизма не придется чем-то особенным жертвовать, например, читаемость кода никак не пострадает. Как говорится, флаг вам в руки – не бойтесь экспериментировать со своим адресным пространством и вызовом mmap в Unix-подобных системах, вызовом CreateFileMapping в Windows, а также разными оберточными функциями, доступными в высокоуровневых языках программирования.
Когда создается отображение файла в память, его содержимое попадает туда не сразу, а постепенно – по мере, того, как процессор отлавливает page faults, вызванные обращением к еще незагруженным фрагментам файла. Обработчик для такого page fault отыщит нужный page-фрейм в страничном кэше и осуществит мэппирование виртуальной страницы в данный page-фрейм. Если нужные данные до этого не были скэшированы в страничном кэше, то будет инициирована операция чтения с диска.
А теперь, вопрос. Представим, что программа render завершила выполнение, и никаких ее дочерних процессов тоже не осталось. Будут ли при этом тут же высвобождены страницы в страничном кэше, хранящие фрагменты файла scene.dat? Многие думают, что да – но это было бы неэффективно. Вообще, если попытаться проанализировать ситуацию, то вот что приходит в голову: достаточно часто мы создаем файл в одной программе, она завершает свое выполнение, затем файл используется в другой программе. Страничный кэш должен предусматривать такие ситуации. И вообще, зачем ядру в принципе избавляться от содержимого страничного кэша? Мы же помним, что скорость работы жесткого диска на пять порядков медленнее оперативной памяти. И если случается так, что данные ранее уже были скэшированы, то нам крупно повезло. Именно поэтому, из страничного кэша ничего не удаляется, по крайней мере до тех пор, пока есть свободная оперативная память. Страничный кэш не зависит от какого-то конкретного процесса, наоборот – это такой ресурс, который совместно использует вся система. Неделю спустя, вновь запустим render, и если файл scene.dat все еще находится в страничном кэше — ну, что ж, нам везет! Вот почему размер страничного кэша постепенно растет, а затем его рост вдруг останавливается. Нет, не потому что операционная система – полная фигня, которая съедает всю оперативу. А потому, что так и должно быть. Неиспользуемая оперативная память – это тоже своего рода напрасно растрачиваемый ресурс. Лучше использовать как можно больше оперативной памяти под страничный кэш, чем вообще никак не использовать.
Когда программа делает вызов write(), данные просто копируются в соответствующую страницу в страничном кэше, и она помечается флагом «dirty». Запись непосредственно на сам жесткий диск не происходит сразу же, и нет смысла блокировать программу в ожидании, пока дисковая подсистема станет доступной. Есть у этого поведения и свой недостаток – если компьютер упадет в синий экран, то данные могут так и не попасть на диск. Именно поэтому критически важные файлы, как например, файлы журнала транзакций баз данных, нужно синхронизировать специальным вызовом fsync() (но вообще, есть еще кэш контроллера жесткого диска, так что и здесь нельзя быть абсолютно уверенным в успешности операции записи). Вызов read() напротив блокирует программу до тех пор, пока диск не станет доступным и данные не будут прочитаны. Для того, чтобы несколько смягчить данную проблему, операционные системы используют т.н. «метод нетерпеливой загрузки» (eager loading), и примером этого метода является «опережающее чтение» (read ahead). Когда задействуется опережающее чтение, ядро производит упреждающую загрузку определенного количества файловых фрагментов в страничный кэш, предвосхищая тем самым последуюшие запросы на чтение. Можно помочь ядру с выбором оптимальных параметров для опережающего чтения, выбрав параметр в зависимости от того, как Вы собираетесь читать файл – последовательно или в произвольном порядке (вызовы madvise(), readahead(), в Windows — cache хинты). Linux использует опережающее чтение для файлов, отраженных в память; насчет Windows я не уверен. Наконец, можно вообще не использовать страничный кэш – за это ответственны флаги O_DIRECT в Linux и NO_BUFFERING в Windows; базы данных так довольно часто и поступают.
Мэппинг файла в память может быть двух типов – или private, или shared. Эти термины обозначают только то, как система будет реагировать на изменение данных в оперативной памяти: в случае с shared-мэппингами любое изменение данных будет сбрасываться на диск или будет видимым в других процессах; в случае с private-мэппингами этого не произойдет. Для реализации private-мэппингов, ядро опирается на механизм copy-on-write, который основан на определенном использовании записей в page-таблицах. В следующем примере, наша программа render, а также программа render3d (а у меня талант на выдумывание названий программ!) создают private-мэппинг для файла scene.dat. Затем, render пишет в область виртуальной памяти, которая поставлена в соответствие файлу:
То, что записи в page-таблицах являются read-only (см. на рисунке) не должно нас смущать; и это еще не означает, что мэппинг будет доступен только на чтение. Это просто такой прием, с помощью которого ядро обеспечивает совместное использование страницы разными процессами и оттягивает необходимость создавать копию страницы до самого последнего момента. Глядя на рисунок понимаешь, что термин “private” возможно и не самый удачный, но если вспомнить, что он описывает исключительно поведение при изменении данных, то все нормально. У механизма мэппирования есть и еще одна особенность. Допустим, есть две программы, которые не связаны отношениями «родительский процесс – дочерний процесс». Программы работают с одним и тем же файлом, но мэппирют его по-разному – в одной программе это private-мэппинг, в другой – shared-мэппинг. Так вот, программа с private-мэппингом (назовем ее «первой программой») будет видеть все изменения, вносимые второй программой в некоторую страницу, до тех пор, пока первая программа сама не попытается записать что-нибудь в эту страницу (что приведет к созданию отдельной копии страницы для первой программы). Т.е. как только отработает механизм copy-on-write, изменения, вносимые другими программами, уже видны не будут. Ядро не гарантирует подобного поведения, но в случае с x86-процессорами так и происходит; и в этом есть определенный смысл, даже с точки зрения того же API.
Что же касается shared-мэппингов, то здесь дела обстоят следующим образом. На страницы выставляются права «read/write», и они просто мэппируются в страничный кэш. Таким образом, кто бы не вносил изменения в страницу, это увидят все процессы. Помимо этого, данные сбрасываются на жесткий диск. Ну и наконец, если страницы на предыдущем рисунке были бы действительно read-only, то page fault, отловленный при обращении к ним, повлек бы за собой ошибку сегментации (segmentation fault), а не отработку логики copy-on-write.
Разделяемые библиотеки также отображаются в память как и любые другие файлы. В этом нет ничего особенного — все тот же private-мэппинг, доступный программисту через вызов API. Далее приводится пример, показывающий часть адресного пространства двух экземпляров программы render, использующих механизм отображения файлов в память. Помимо этого, показаны соответствующие области физической памяти. Таким образом мы можем увязать вместе те концепций, с которыми познакомились в данной статье:
На этом завершим нашу серию из трёх статей, посвященных основам работы памяти. Надеюсь информация была для вас полезной и позволила составить общее представление по данной теме.