Глава 11. Управление памятью ядра

(номер панели переключения + номер комнаты) <=> частный (реальный) номер телефона
 	   

На протяжении данной главы такие термины как пространство ядра (kernel space) и пространство пользователя (user space) будут относиться к их виртуальному адресному пространству. В системах Linux всякий процесс обладает собственным виртуальным адресным пространством. Это некий вид песочница памяти на время жизни данного процесса. В системах с 32 битами это адресное пространство составляет 4ГБ в размере (даже для систем с физическим размером менее 4ГБ). Для каждого процесса это адресное пространство в 4ГБ расщепляется на две части:

Тот способ, которым осуществляется данное расщепление зависит от специальной опции настройки ядра, CONFIG_PAGE_OFFSET, которая определяет где начинаются адреса самого ядра в адресном пространстве некоего процесса. Обычным значением является значение по умолчанию 0xC0000000 в 32- битных системах, однако его можно изменять, как это имеет место в случае процессоров семейства i.MX6 от NXP, которые используют 0x80000000. Во всей данной главе мы будем считать значением по умолчанию адрес 0xC0000000. Такое расщепление именуется как расщепление 3G/1G, при котором пространству пользователя предоставляются нижние 3ГБ виртуального адресного пространства, а само ядро применяет оставшийся 1ГБ верхних адресов. Некая типичная схема виртуального адресного пространства процесса выглядит следующим образом:

.------------------------. 0xFFFFFFFF
|                        | (4 GB)
|    Kernel addresses    |
|                        |
|                        |
.------------------------.CONFIG_PAGE_OFFSET
|                        |(x86: 0xC0000000, ARM: 0x80000000)
|                        |
|                        |
|  User space addresses  |
|                        |
|                        |
|                        |
|                        |
'------------------------' 00000000
 	   

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

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

Управление элементами всей памяти организовано в виде единиц фиксированного размера, именуемых страницами. Страница содержит 4 096 байт (4кБ). Даже хотя данный размер может отличаться в прочих системах, он фиксирован в ARM и x86, архитектурами которых мы интересуемся:

Так как некая страница памяти ставится в соответствие страничному блоку, само собой разумеется, что страницы и страничные блоки имеют один и тот же размер, в нашем случае 4кБ. Данный размер страницы определяется в самом ядре посредством макроса PAGE_SIZE.

Ядро Linux имеет своё собственное виртуальное адресное пространство, как это имеется в случае режима каждого процесса пользователя. Такое виртуальное адресное пространство самого ядра (с размером в 1ГБ при расщеплении 3G/1G) подразделяется на две части:

                                        Physical mem
   Process address space     +------> +------------+
                             |        |  3200 M    |
                             |        |            |
4 GB +---------------+ <-----+        |  HIGH MEM  |
     |    128 MB     |                |            |
     +---------------+ <---------+    |            |
     +---------------+ <------+  |    |            |
     |    896 MB     |        |  +--> +------------+
3 GB +---------------+ <--+   +-----> +------------+
     |               |    |           |   896 MB   | LOW MEM
     |    /////      |    +---------> +------------+
     |               |
0 GB +---------------+
 	   

 

Нижние адреса памяти

 

Верхние адреса памяти

struct task_struct{
    [...]
    struct mm_struct *mm, *active_mm;
    [...]
}
 	   

struct mm_struct {
        struct vm_area_struct *mmap;
        struct rb_root mm_rb;
        unsigned long mmap_base;
        unsigned long task_size;
        unsigned long highest_vm_end;
        pgd_t * pgd;
        atomic_t mm_users;
        atomic_t mm_count;
        atomic_long_t nr_ptes;
#if CONFIG_PGTABLE_LEVELS > 2
        atomic_long_t nr_pmds;
#endif
        int map_count;
        spinlock_t page_table_lock;
        struct rw_semaphore mmap_sem;
        unsigned long hiwater_rss;
        unsigned long hiwater_vm;
        unsigned long total_vm;
        unsigned long locked_vm;
        unsigned long pinned_vm;
        unsigned long data_vm;
        unsigned long exec_vm;
        unsigned long stack_vm;
        unsigned long def_flags;
        unsigned long start_code, end_code, start_data, end_data;
        unsigned long start_brk, brk, start_stack;
        unsigned long arg_start, arg_end, env_start, env_end;

        /* Architecture-specific MM context */
        mm_context_t context;

        unsigned long flags;
        struct core_state *core_state;
#ifdef CONFIG_MEMCG
        /*
         * "owner" points to a task that is regarded as the canonical
         * user/owner of this mm. All of the following must be true in
         * order for it to be changed:
         *
         * current == mm->owner
         * current->mm != mm
         * new_owner->mm == mm
         * new_owner->alloc_lock is held
         */
        struct task_struct __rcu *owner;
#endif
        struct user_namespace *user_ns;
        /* store ref to file /proc/<pid>/exe symlink points to */
        struct file __rcu *exe_file;
};
 	   

# cat /proc/1073/maps
00400000-00403000 r-xp 00000000 b3:04 6438 /usr/sbin/net-listener
00602000-00603000 rw-p 00002000 b3:04 6438 /usr/sbin/net-listener
00603000-00624000 rw-p 00000000 00:00 0 [heap]
7f0eebe4d000-7f0eebe54000 r-xp 00000000 b3:04 11717 /usr/lib/libffi.so.6.0.4
7f0eebe54000-7f0eec054000 ---p 00007000 b3:04 11717 /usr/lib/libffi.so.6.0.4
7f0eec054000-7f0eec055000 rw-p 00007000 b3:04 11717 /usr/lib/libffi.so.6.0.4
7f0eec055000-7f0eec069000 r-xp 00000000 b3:04 21629 /lib/libresolv-2.22.so
7f0eec069000-7f0eec268000 ---p 00014000 b3:04 21629 /lib/libresolv-2.22.so
[...]
7f0eee1e7000-7f0eee1e8000 rw-s 00000000 00:12 12532 /dev/shm/sem.thk-mcp-231016-sema
[...]
 	   

/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */
extern struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr);
 	   

struct vm_area_struct *vma = find_vma(task->mm, 0x13000);
if (vma == NULL) /* Not found ? */
    return -EFAULT;
if (0x13000 >= vma->vm_end) /* Beyond the end of returned VMA ? */
    return -EFAULT;
 	   

#define PAGE_SHIFT     12
#ifdef __ASSEMBLY__
#define PAGE_SIZE      (1 << PAGE_SHIFT)
#else
#define PAGE_SIZE      (1UL << PAGE_SHIFT)
#endif
 	   

 

Как работает TLB

 

API блока выделения страниц

 

Функции преобразования

 

Алгоритм распределения buddy

 

Прогулка по распределению slab

 

Вариант копирования записью (CoW)

Отображаемый в памяти ввод/ вывод (MMIO, Memory-mapped I/O) находится в том же самом пространстве адресов, что и память. Имеющееся ядро применяет часть существующего адресного пространства обычно применяется оперативной памятью (RAM, фактически, HIGH_MEM) для установления соответствия регистрам устройств с тем, чтобы вместо наличия по этим адресам действительной памяти (то есть оперативной памяти, RAM), там находятся устройства ввода/ вывода. Тем самым взаимодействие с неким устройством ввода/ вывода становится подобным чтению и записи по адресам памяти приданых этому устройству ввода/ вывода.

Как и в случае PIO, имеются функции MMIO для информирования ядра о нашем намерении применять некую область памяти. Помните, что это всего лишь резервирование. Существуют request_mem_region() и release_mem_region():

struct resource* request_mem_region(unsigned long start,
                                    unsigned long len, char *name)
void release_mem_region(unsigned long start, unsigned long len)
 	   

Это к тому же некая учтивость.

Прежде чем осуществить доступ к некоторой области памяти (и после того как вы успешно запросили её), эта область должна быть поставлена в соответствие в адресном пространстве ядра путём вызова особых зависящих от архитектуры функций (которые применяют MMU для построения необходимой таблицы страниц и, таким образом, не могут вызываться из имеющихся обработчиков прерывания). Имеются также ioremap() и iounmap():

void __iomem *ioremap(unsigned long phys_add, unsigned long size)
void iounmap(void __iomem *addr)
 	   

ioremap() возвращает некий указатель __iomem void на самое начало такой области соответствия. Не подвергайте себя искушению применять (получать/ устанавливать необходимое значение путём чтения/ записи по этому указателю) такие указатели. Имеющееся ядро предоставляет функции для доступа к памяти, поставленной в соответствие вводу/ выводу. Вот они:

unsigned int ioread8(void __iomem *addr);
unsigned int ioread16(void __iomem *addr);
unsigned int ioread32(void __iomem *addr);
void iowrite8(u8 value, void __iomem *addr);
void iowrite16(u16 value, void __iomem *addr);
void iowrite32(u32 value, void __iomem *addr);
 	   

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

 

Куки __iomem

__iomem является объектом куки (cookie) ядра, применяемого Sparse, блока синтаксического разбора, используемого имеющимся ядром для поиска возможных отказов в коде. Для получения преимуществ от предлагаемой Sparse функциональности она должна быть включена во время компиляции ядра; если это не так, __iomem будет в любом случее проигнорирован.

Присвоение c=1 в соответствующей командной строке включит для вас Sparse, однако вначале необходимо установить в вашей системе синтаксический разбор:

sudo apt-get install sparse
		

Например, при построении некоего модуля воспользуйтесь:

make -C $KPATH M=$PWD C=1 modules
		

В качестве альтернативы, в случае когда написан надлежащий makefile, просто наберите:

make C=1
		

Приводимое ниже определение показывает как __iomem задаётся в самом ядре:

#define __iomem    __attribute__((noderef, address_space(2)))
		

Оно предостерегает нас от ошибочного применения драйверами доступа к памяти ввода/ вывода. Добавление __iomem для всего доступа ввода/ вывода является неким способом, которому необходимо строго следовать. Так как даже доступ к вводу/ выводу осуществляется через виртуальную память (в системах с MMU), эти объекты куки оберегают нас от применения абсолютных физических адресов, а также требует от нас применения ioremap(), которая возвратит некий виртуальный адрес, помеченный объектом куки __iomem:

void __iomem *ioremap(phys_addr_t offset, unsigned long size);
		

Поэтому мы можем применять специально предназначенные функции, такие как ioread32() и iowrite32(). Вы можете удивиться почему бы не применить обычные функции readl()/ writel(). Они отклоняются по той причине, поскольку они не выполняют проверку на вменяемость и менее безопасны (не требуют никаких __iomem) в отличии от семейства функций ioreadX()/ iowriteX(), которые применяют только адреса __iomem.

Кроме того, noderef является неким атрибутом, который применяется Sparse чтобы гарантировать программистам и не выполнять разименование некоего указателя __iomem. Даже несмотря на то, что это может работать в какой- то архитектуре, настоятельно не рекомендуется поступать так. Применяйте вместо этого специальные функции ioreadX()/ iowriteX(). Именно они являются переносимыми и работают в любых архитектурах. Теперь позвольте нам показать как Sparse будет предостерегать нас при разименовании какого- то указателя __iomem:

#define BASE_ADDR 0x20E01F8
void * _addrTX = ioremap(BASE_ADDR, 8);
		

Во первых, Sparse не удовлетворится по причине начальной инициализации:

warning: incorrect type in initializer (different address spaces)expected void *_addrTXgot void [noderef] <asn:2>*
		

Либо:

u32 __iomem* _addrTX = ioremap(BASE_ADDR, 8);
*_addrTX = 0xAABBCCDD; /* плохо. Никакого разименования */
pr_info("%x\n", *_addrTX); /* плохо. Никакого разименования */
		

Sparse всё ещё не будет удовлетворён:

New-VM -Name VM01 -Generation 2
		

Наш последний пример удовлетворяет Sparse:

void __iomem* _addrTX = ioremap(BASE_ADDR, 8);
iowrite32(0xAABBCCDD, _addrTX);
pr_info("%x\n", ioread32(_addrTX));
		

Двумя правилами, которые вам следует запомнить являются:

 

Применение remap_pfn_range

 

Применение io_remap_pfn_range

 

Файловые операции mmap

 

Реализация mmap в самом ядре

 

Кэш ЦПУ - кэширование памяти

 

Кэширование страниц Linux - кэш диска

 

Специализированное кэширование (кэширование пространства пользователя)

 

Стратегии кэширования записи

 

Потоки сброса