Роберт Лав - Разработка ядра Linux
В связи с этим, для выделения больших объемов памяти необходимо использовать одну из динамических схем выделения памяти, которые были рассмотрены раньше в этой главе.
Отображение верхней памяти
По определению, страницы верхней памяти не могут постоянно отображаться в адресное пространство ядра. Поэтому страницы памяти, которые были выделены с помощью функции alloc_pages(), при использовании флага __GFP__HIGHMEM могут не иметь логического адреса.
Для аппаратной платформы x86 вся физическая память свыше 896 Мбайт помечается как верхняя память, и она не может автоматически или постоянно отображаться в адресное пространство ядра, несмотря на то что процессоры платформы x86 могут адресовать до 4 Гбайт физической памяти (до 64 Гбайт при наличии расширения РАЕ[66]). После выделения эти страницы должны быть отображены в логическое адресное пространство ядра. Для платформы x86 страницы верхней памяти отображаются где-то между отметками 3 и 4 Гбайт.
Постоянное отображение
Для того чтобы отобразить заданную структуру page в адресное пространство ядра, необходимо использовать следующую функцию.
void *kmap(struct page *page);
Эта функция работает как со страницами нижней, так и верхней памяти. Если структура page соответствует странице нижней памяти, то просто возвращается виртуальный адрес. Если страница расположена в верхней памяти, то создается постоянное отображение этой страницы памяти и возвращается полученный логический адрес. Функция kmap() может переводить процесс в состояние ожидания, поэтому ее можно вызывать только в контексте процесса.
Поскольку количество постоянных отображений ограничено (если бы это было не так, то мы бы не мучились, а просто отобразили всю необходимую память), то отображение страниц верхней памяти должно быть отменено, если оно больше не нужно. Это можно сделать с помощью вызова следующей функции.
void kunmap(struct page *page);
Данная функция отменяет отображение страницы памяти, связанной с параметром page.
Временное отображение
В случаях, когда необходимо создать отображение страниц памяти в адресное пространство, а текущий контекст не может переходить в состояние ожидания, ядро предоставляет функцию временного отображении (которое также называется атомарным отображением). Существует некоторое количество зарезервированных постоянных отображений, которые могут временно выполнять отображение "на лету". Ядро может автоматически отображать страницу верхней памяти в одно из зарезервированных отображений. Временное отображение может использоваться в коде, который не может переходить в состояние ожидания, как, например, контекст прерывания, потому что полученное отображение никогда не блокируется.
Установка временного отображения выполняется с помощью следующей функции.
void *kmap_atomic(struct page *page, enum km_type type);
Параметр type — это одно из значений показанного ниже перечисления, определенного в файле <asm/kmap_types.h>, которое описывает цель временного отображения.
enum km_type {
KM_BOUNCE_READ,
KM_SKB_SUNRPC_DATA,
KM_SKB_DATA_SOFTIRQ,
KM_USER0,
KM_USER1,
KM_BIO_SRC_IRQ,
KM_BIO_DST_IRQ,
KM_PTE0,
KM_PTE1,
KM_PTE2,
KM_IRQ0,
KM_IRQ1,
KM_SOFTIRQ0,
KM_SOFTIRQ1,
KM_TYPE_NR
};
Данная функция не блокируется и поэтому может использоваться в контексте прерывания и в других случаях, когда нельзя перепланировать выполнение. Эта функция также запрещает преемптивность ядра, что необходимо потому, что отображения являются уникальными для каждого процессора (а перепланирование может переместить задание для выполнения на другом процессоре).
Отменить отображение можно с помощью следующей функции.
void kunmap_atomic(void *kvaddr, enum km_type type);
Эта функция также не блокирующая. На самом деле для большинства аппаратных платформ она ничего не делает, за исключением разрешения преемптивности ядра, потому что временное отображение действует только до тех пор, пока не создано новое временное отображение. Поэтому ядро просто "забывает" о вызове функции kmap_atomic(), и функции kunmap_atomic() практически ничего не нужно делать. Следующее атомарное отображение просто заменяет предыдущее.
Выделение памяти, связанной с определенным процессором
В современных операционных системах широко используются данные, связанные с определенными процессорами (per-CPU data). Это данные, которые являются уникальными для каждого процессора. Данные, связанные с процессорами, хранятся в массиве. Каждый элемент массива соответствует своему процессору системы. Номер процессора является индексом в этом массиве. Таким образом была реализована работа с данными, связанными с определенным процессором, в ядрах серии 2.4. В таком подходе нет ничего плохого, поэтому значительная часть кода ядра в серии 2.6 все еще использует этот интерфейс. Данные объявляются следующим образом,
unsigned long my_percpu[NR_CPUS];
Доступ к этим данным выполняется, как показано ниже.
int cpu;
cpu = get_cpu(); /* получить номер текущего процессора и запретить
вытеснение в режиме ядра */
my_percpu[cpu]++;
printk("значение данных процессора cpu=%d равно %ldn",
cpu, my_percpu[cpu]);
put_cpu(); /* разрешить вытеснение в режиме ядра */
Обратите внимание, что не нужно использовать никаких блокировок, потому что данные уникальны для каждого процессора. Поскольку никакой процессор, кроме текущего, не может обратиться к соответствующему элементу данных, то не может возникнуть и никаких проблем с конкурентным доступом, а следовательно, текущий процессор может безопасно обращаться к данным без блокировок.
Возможность вытеснения процессов в режиме ядра— единственное, из-за чего могут возникнуть проблемы. В преемптивном ядре могут возникнуть следующие две проблемы.
• Если выполняющийся код вытесняется и позже планируется для выполнения на другом процессоре, то значение переменной cpu больше не будет действительным, потому что эта переменная будет содержать номер другого процессоpa. (По той же причине, после получения номера текущего процессора, нельзя переходить в состояние ожидания.)
• Если некоторый другой код вытеснит текущий, то он может параллельно обратиться к переменной my_percpu на том же процессоре, что соответствует состоянию гонок за ресурс.
Однако все опасения напрасны, потому что вызов функции get_cpu(), которая возвращает номер текущего процессора, также запрещает вытеснение в режиме ядра. Соответствующий вызов функции put_cpu() разрешает вытеснение кода в режиме ядра. Обратите внимание, что функция smp_processor_id(), которая также позволяет получить номер текущего процессора, не запрещает вытеснения кода в режиме ядра, поэтому для безопасной работы следует использовать указанный выше метод.
Новый интерфейс percpu
В ядрах серии 2.6 предложен новый интерфейс, именуемый percpu, который служит для создания данных и работы с данными, связанными с определенным процессором. Этот интерфейс обобщает предыдущий пример. При использовании нового подхода работа с per-CPU-данными упрощается.
Рассмотренный ранее метод работы с данными, которые связаны с определенным процессором, является вполне законным. Новый интерфейс возник из необходимости иметь более простой и мощный метод работы с данными, связанными с процессорами, на больших компьютерах с симметричной мультипроцессорностью.
Все подпрограммы объявлены в файле <linux/percpu.h>. Описания же находятся в файлах mm/slab.с и <asm/percpu.h>.
Работа с данными, связанными с процессорами, на этапе компиляции
Описать переменную, которая связана с определенным процессором, на этапе компиляции можно достаточно просто следующим образом.
DEFINE_PER_CPU(type, name);
Это описание создает переменную типа type с именем name, которая имеет интерфейс связи с каждым процессором в системе. Если необходимо объявить соответствующую переменную с целью избежания предупреждений компилятора, то необходимо использовать следующий макрос.
DECLARE_PER_CPU(type, name);
Работать с этими переменными можно с помощью функций get_cpu_var() и put_cpu_var(). Вызов функции get_cpu_var() возвращает l-значение (левый операнд, l-value) указанной переменной на текущем процессоре. Этот вызов также запрещает вытеснение кода в режиме ядра, а соответственный вызов функции put_cpu_var() разрешает вытеснение.
