Разработка ядра Linux

Глава 15 Страничный кэш и обратная запись страниц

В ядре операционной системы Linux реализован один главный дисковый кэш, который называется страничным (page cache). Назначение этого кэша — минимизировать количество дисковых операций ввода-вывода путем хранения в памяти тех данных, для обращения к которым необходимо выполнять дисковые операции, Эта глава посвящена рассмотрению страничного кэша.

Кэширование дисковых данных важно по двум причинам. Во-первых, доступ к диску выполняется значительно медленнее, чем доступ к памяти. Доступ к данным в памяти выполняется значительно быстрее, чем к данным на диске. Во-вторых, если к некоторым данным осуществлялся доступ, то с достаточно большой вероятностью к этим же данным в ближайшем будущем потребуется обратиться снова. Принцип, согласно которому операции обращения к некоторым данным имеют тенденцию группироваться друг с другом во времени, называется сосредоточенностью во времени (temporal locality). Сосредоточенность во времени гарантирует, что если данные кэшируются при первом доступе к ним, то существует большая вероятность удачного обращения в кэш к этим данным в ближайшем будущем.

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

Отдельные дисковые блоки также могут быть привязаны к страничному кэшу с помощью буферов блочного ввода-вывода. Вспомните из материала главы 13, "Уровень блочного ввода-вывода", что буфер — это представление в памяти одного физического дискового блока. Буферы играют роль дескрипторов, которые отображают страницы памяти на дисковые блоки. Поэтому страничный кэш также позволяет сократить количество обращений к диску при выполнении операций блочного ввода-вывода как за счет кэширования, так и за счет буферизации операций блочного ввода-вывода для выполнения в будущем. Такой тип кэширования часто называют "буферным кэшем", хотя на самом деле это не отдельный кэш, а часть страничного кэша.

Рассмотрим те типы операций и данных, которые связаны со страничным кэшем. Страничный кэш в основном пополняется при выполнении страничных операций ввода-вывода, таких как

read()

write()

. Страничные операции ввода-вывода выполняются с целыми страницами памяти, в которых хранятся данные, что соответствует операциям с более, чем одним дисковым блоком. В страничном кэше данные файлов хранятся порциями. Размер одной порции равен одной странице памяти.

Операции блочного ввода-вывода работают в каждый отдельный момент времени с одним дисковым блоком. Часто встречающаяся операция блочного ввода-вывода — это чтение и запись файловых индексов. Ядро предоставляет функцию

bread()

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

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

Страничный кэш

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

read()

[84], ядро проверяет, есть ли те данные, которые нужно считать, в страничном кэше. Если данные находятся в кэше, то ядро может быстро возвратить требуемую страницу памяти.

Объект

address_space

Физическая страница памяти может содержать данные из нескольких несмежных физических дисковых блоков[85].

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

Более того, страничный кэш ядра Linux является хранилищем данных достаточно общего характера в отношении того, какие страницы памяти в нем могут кэшироваться. Первоначально страничный кэш был предложен в операционной системе System V (SVR 4) для кэширования только данных из файловых систем. Следовательно, для управления страничным кэшем операционной системы SVR 4 использовался эквивалент файлового объекта, который назывался

struct vnode

. Кэш операционной системы Linux разрабатывался с целью кэширования любых объектов, основанных на страницах памяти, что включает множество типов файлов и отображений в память.

Для получения необходимой общности в страничном кэше операционной системы Linux используется структура

address_space

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

следующим образом.

struct address_space {

 struct inode           *host;   /* файловый индекс, которому

                        принадлежит объект */

 struct radix_tree_root      page_tree; /* базисное дерево

                         всех страниц */

 spinlock_t            tree_lock; /* блокировка для защиты

                        поля page_tree */

 unsigned int           i_mmap_wrltable; /* количество областей

                        памяти

 с флагом VM_SHARED */

 struct prio_tree_root      i_mmap;  /* список всех отображений */

 struct list_head         i_mmap_nonlinear; /* список областей

                     памяти с флагом VM_NONLINEAR */

 spinlock_t            i_mmap_lock; /* блокировка поля i_mmap */

 atomic_t             truncate_count; /* счетчик запросов

                           truncate */

 unsigned long          nrpages; /* общее количество страниц */

 pgoff_t             writeback_index; /* смещения начала

                            обратной записи */

 struct address_space_operations *a_ops;     /* таблица операций */

 unsigned long          flags;      /* маска gfp_mask

                            и флаги ошибок */

 struct backing_dev_info     *backing_dev_info; /* информация

                      упреждающего чтения */

 spinlock_t            private_lock; /* блокировка

                   для частных отображений */

 struct list_head         private_list; /* список

                          частных отображений */

 struct address_spacs       *assoc_mapping; /* соответствующие

                           буферы */

};

Поле

i_mmap

— это дерево поиска по приоритетам для всех совместно используемых и частных отображений. Дерево поиска по приоритетам— это хитрая смесь базисных и частично упорядоченных бинарных деревьев[86].

Всего в адресном пространстве nrpages страниц памяти.

Объект

address_space

связан с некоторым другим объектом ядра, обычно с файловым индексом. Если это так, то поле

host

указывает на соответствующий файловый индекс. Если значение поля

host

равно

NULL

, то соответствующий объект не является файловым индексом; например, объект

address_space

может быть связан с процессом подкачки страниц (swapper).

Поле

a_ops

указывает на таблицу операций с адресным пространством так же, как и в случае объектов подсистемы VFS. Таблица операций представлена с помощью структуры

struct address_space_operations

, которая определена в файле

следующим образом.

struct address_space_operations {

 int (*writepage)(struct page*, struct writeback_control*);

 int (*readpage)(struct file*, struct page*);

 int (*sync_page)(struct page*);

 int (*writepages)(struct address_space*,

  struct writeback_control*);

 int (*set_page_dirty)(struct page*);

 int (*readpages)(struct file*, struct address_space*,

  struct list_head*, unsigned);

 int (*prepare_write)(struct file*, struct page*,

  unsigned, unsigned);

 int (*commit_write)(struct file*, struct page*,

  unsigned, unsigned);

 sector_t (*bmap)(struct address_space*, sector_t);

 int (*invalidatepage)(struct page*, unsigned long);

 int (*releasepage)(struct page*, int);

 int (*direct_IO)(int, struct kiocb*, const struct iovec*,

  loff_t, unsigned long);

};

Методы

read_page

write_page

являются наиболее важными. Рассмотрим шаги, которые выполняются при страничной операции чтения.

Методу чтения в качестве параметров передается пара значений: объект

address_space

и смещение. Эти значения используются следующим образом для поиска необходимых данных в страничном кэше.

page = find_get_page(mapping, index);

где параметр

mapping

— это заданное адресное пространство, a

index

— заданная позиция в файле.

Если в кэше нет необходимой страницы памяти, то новая страница памяти выделяется и добавляется в кэш следующим образом.

struct page *cached_page;

int error;

cached_page = page_cache_alloc_cold(mapping);

if (!cached_page)

 /* ошибка выделения памяти */

error =

 add_to_page_cache_lru(cached_page, mapping, index, GFP_KERNEL);

if (error)

 /* ошибка добавления страницы памяти в страничный кэш */

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

error = mapping->a_ops->readpage(file, page);

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

SetPageDirty(page);

Ядро выполняет запись этой страницы памяти позже с помощью вызова метода

writepage()

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

mm/filemap.с

, включает следующие шаги.

page =

 __grab_cache_page(mapping, index, &cached_page, &lru_pvec);

status =

 a_ops->prepare_write(file, page, offset, offset+bytes);

page_fault =

 filemap_copy_from_user(page, offset, buf, bytes);

status =

 a_ops->commit_write(file, page, offset, offset+bytes);

Выполняется поиск необходимой страницы памяти в кэше. Если такая страница в кэше не найдена, то создается соответствующий элемент кэша. Затем вызывается метод

prepare_write()

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

commit_write()

Поскольку все описанные шаги выполняются при всех операциях страничного ввода-вывода, то все операции страничного ввода-вывода выполняются только через страничный каш. Ядро пытается выполнить все запросы чтения из страничного кэша. Если этого сделать не удается, то страница считывается с диска и добавляется в страничный кэш. Для операций записи страничный кэш выполняет роль "стартовой площадки". Следовательно, все записанные страницы также добавляются в страничный кэш.

Базисное дерево

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

Как было показано в предыдущем разделе, поиск в страничном кэше выполняется на основании информации объекта

address_space

и значения смещения. Каждый объект

address_space

имеет свое уникальное базисное дерево (radix tree), которое хранится в поле

page_tree

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

find_get_page()

radix_tree_lookup()

, выполняют поиск с использованием заданного дерева и заданного объекта.

Основной код для работы с базисными деревьями находится в файле

lib/radix-tree.c

. Для использования базисных деревьев необходимо подключить заголовочный файл

Старая хеш-таблица страниц

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

NULL

Использование глобальной хеш-таблицы приводило к четырем основным проблемам.

• Хеш-таблица защищалась одной глобальной блокировкой. Количество конфликтов при захвате этой блокировки было достаточно большим даже для не очень больших машин. В результате страдала производительность.

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

• Производительность в случае неудачного обращения в кэш (когда искомая страница памяти не находится в кэше) падала из-за необходимости просматривать все элементы списка, связанного с заданным ключом.

• Хеш-таблица требовала больше памяти, чем другие возможные решения.

Применение в ядрах серии 2.6 страничного кэша на основании базисных деревьев позволило решить эти проблемы.

Буферный кэш

В операционной системе Linux больше нет отдельного буферного кэша. В ядрах серии 2.2 существовало два отдельных кэша: страничный и буферный. В первом кэшировались: страницы памяти, а в другом — буферы. Эти два кэша не были объединены между собой. Дисковый блок мог находиться в обоих кэшах одновременно. Это требовало больших усилий по синхронизации двух кэшированных копий, не говоря уже о напрасной трате памяти.

Так было в ядрах серии 2.2 и более ранних, но начиная с ядер Linux серии 2.4 оба кэша объединили вместе. Сегодня существует только один дисковый кэш — страничный кэш.

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

Демон

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

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

Демоны

bdflush

kupdated

В ядрах серий до 2.6 работа потоков

pdflush

выполнялась двумя другими потоками ядра

bdflush

kupdated

Поток пространства ядра

bdflush

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

pdflush

. Демон

bdflush

возвращался к выполнению с помощью функции

wakeup_bdflush()

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

Между демонами

bdflush

pdflush

существует два главных отличия. Первое состоит в том, что демон

bdflush

был всего один, а количество потоков

pdflush

может меняться динамически. Об этом более подробно будет рассказано в следующем разделе. Второе отличие состоит в том, что демон

bdflush

работал с буферами, он записывал на диск измененные буферы. Демон

pdflush

работает со страницами, он записывает на диск целые измененные страницы памяти. Конечно, страницы памяти могут соответствовать буферам, но единицей ввода-вывода является целая страница памяти, а не один буфер. Это дает преимущество, поскольку работать со страницами памяти проще, чем с буферами, так как страница памяти — более общий и более часто используемый объект.

Так как демон

bdflush

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

kupdated

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

wb_kupdate()

демона

pdflush

Потоки

bdflush

kupdated

и их функциональность сейчас заменены потоками

pdflush

Предотвращение перегруженности: для чего нужны несколько потоков

Один из главных недостатков решения на основе демона

bdflush

состоит в том, что демон

bdflush

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

bdflush

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

bdflush

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

В ядрах серии 2.6 эта проблема решается путем введения нескольких потоков

pdflush

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

pdflush

работать с разными очередями запросов устройств.

Количество потоков изменяется в процессе работы системы в соответствии с простым алгоритмом. Если все существующие потоки

pdflush

оказываются занятыми в течение одной секунды, то создается новый поток

pdflush

. Общее количество потоков не может превышать значения константы

MAX_PDFLUSH_THREADS

, которая по умолчанию равна 8. И наоборот, если поток pdflush находился в состоянии ожидания больше одной секунды, то он уничтожается. Минимальное количество потоков равно, по крайней мере, значению константы

MIN_PDFLUSH_THREADS,

что по умолчанию соответствует 2. Таким образом, количество потоков

pdflush

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

pdflush

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

pdflush

уменьшается, чтобы освободить память.

Всё это хорошо, но что если все потоки

pdflush

зависнут в ожидании записи в одну и ту же перегруженную очередь? В этом случае производительность нескольких потоков

pdflush

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

pdflush

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

pdflush

распределяют свою работу по разным очередям и воздерживаются от записи в перегруженную очередь. Когда все потоки

pdflush

заняты работой и запускается новый поток, то это означает, что они действительно заняты.

В связи с усовершенствованием алгоритмов обратной записи страниц, включая введение демона

bdflush

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

pdflush

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

Коротко о главном

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

pdflush

На основании материала последних нескольких глав вы получили устойчивое представление о том, как выполняется управление памятью и файловыми системами. Теперь давайте перейдем к теме модулей и посмотрим, ядро Linux обеспечивает модульную и динамическую инфраструктуру для загрузки кода ядра во время работы системы.