Перш ніж ми обговоримо особливості , що стосуються pdflush, kjournald, andkswapd`, давайте спочатку отримати трохи про контекст того , що саме ми говоримо в термінах ядра Linux.
Архітектура GNU / Linux
Архітектуру GNU / Linux можна розглядати як два простори:
Між простір користувача та простір ядра сидить бібліотека GNU C ( glibc). Це забезпечує інтерфейс системного виклику, який з'єднує ядро з програмами користувальницького простору.
Простір ядра можна додатково розділити на 3 рівні:
- Інтерфейс системного виклику
- Код архітектурного незалежного ядра
- Код залежно від архітектури
Інтерфейс системного виклику, як випливає з його назви, забезпечує інтерфейс між glibcядром та ядром. Архітектурний Незалежний Kernel Код складається з логічних одиниць , таких як VFS (Virtual File System) і VMM (Virtual Memory Management). Архітектурний залежний код є компонентами, процесор і від платформи залежний код для конкретної апаратної архітектури.
Діаграма архітектури GNU / Linux
У решті цієї статті ми зосередимо свою увагу на логічних одиницях VFS та VMM у просторі ядра.
Підсистеми ядра GNU / Linux
Підсистема VFS
Маючи концепцію високого рівня того, як структуровано ядро GNU / Linux, ми можемо заглибитися трохи глибше в підсистему VFS. Цей компонент відповідає за забезпечення доступу до різних пристроїв зберігання блоків, які в кінцевому підсумку відображаються у файловій системі (ext3 / ext4 / тощо.) На фізичному пристрої (HDD / тощо).
Діаграма VFS
Ця діаграма показує, як write()процес користувача проходить VFS і в кінцевому підсумку просувається до драйвера пристрою, де він записується на фізичний носій інформації. Це перше місце, де ми стикаємось pdflush. Це демон, який відповідає за передачу брудних блоків даних та блоків метаданих на носій інформації у фоновому режимі. На схемі цього не видно, але є інший демон, kjournaldякий сидить поруч pdflush, виконуючи аналогічне завдання, записуючи брудні журнальні блоки на диск. ПРИМІТКА: Блоки журналів - це те, як файлові системи типу ext4 та JFS відслідковують зміни на диску у файлі до тих змін, які відбудуться.
Наведені деталі розглядаються далі в цій роботі .
Огляд write()кроків
Щоб забезпечити простий огляд операцій з системою вводу-виводу, ми будемо використовувати приклад, коли програма write()викликає додаток User Space.
- Процес вимагає записати файл через
write()системний виклик.
- Ядро оновлює кеш сторінки, відображений у файл.
- Нитка ядра pdflush піклується про те, щоб передати кеш сторінки на диск.
- Рівень файлової системи з'єднує кожен блок-буфер разом з
bio struct( див. 1.4.3, «Блоковий рівень» на стор. 23 ) і подає запит на запис на рівень пристрою блоку.
- Рівень блокового пристрою отримує запити від верхніх шарів і виконує операцію ліфта вводу / виводу і ставить запити в чергу запитів вводу / виводу.
- Драйвер пристрою, такий як SCSI або інші драйвери для певних пристроїв, подбає про роботу запису.
- Прошивка дискового пристрою виконує апаратні операції, такі як пошук голови, обертання та передача даних у сектор на тарілці.
Підсистема VMM
Продовжуючи глибше занурення, ми тепер можемо заглянути в підсистему VMM. Цей компонент відповідає за підтримку узгодженості між основною пам'яттю (ОЗП), свопом та фізичним носієм зберігання. Основним механізмом збереження консистенції є bdflush. Оскільки сторінки пам'яті вважаються брудними, їх потрібно синхронізувати з даними, які є на носії. bdflushкоординуватиме з pdflushдемонами, щоб синхронізувати ці дані з носієм інформації.
Діаграма ВММ
Зміна
Коли системна пам'ять стає дефіцитною чи закінчується таймер заміни ядра, kswapdдемон намагатиметься звільнити сторінки. Поки кількість безкоштовних сторінок залишається вище free_pages_high, kswapdнічого не призведе. Однак, якщо кількість безкоштовних сторінок kswapdзменшиться нижче, тоді розпочнеться процес рекультивації сторінки. Після того, kswapdяк позначені сторінки для переїзду, bdflushвони подбають про синхронізацію будь-яких непогашених змін на носії інформації через pdflushдемони.
Посилання та подальші читання