WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 10 |

«; ...»

-- [ Страница 5 ] --

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

Определение секвентной блокировки можно записать следующим образом.

seqlock_t mr_seq_lock = SEQLOCK_UNLOCKED

;

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

write_seqlock(&mr_seq_lock)

;

/* блокировка захвачена на запись... */ write_sequnlock(&mr_seq_lock)

;

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

unsigned long seq

;

do { seq = read_seqbegin(&mr_seq_lock)

;

/* здесь нужно читать данные... */ } while (read_seqretry(&mr_seq_lock, seq))

;

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

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

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

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

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

200 Глава Для решения указанной проблемы преемптивность ядра можно запретить с по мощью функции preempt_disable (). Этот вызов может быть вложенным, т.е.

функцию можно вызывать много раз подряд. Для каждого такого вызова требуется соответствующий вызов функции preerapt_enable (). Последний вызов функции preemptenable() разрешает преемптивность, как показано в следующем примере.

preempt_disable()

;

/* преемптивность запрещена... */ preempt_enable()

;

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

Таблица 9.9. Функции управления преемптивностыо ядра Функция Описание preempt_disable() Запретить вытеснение кода ядра preempt_enable() Разрешить вытеснение кода ядра preempt_enable_no_resched() Разрешить вытеснение кода ядра, но не перепланировать выполнение процесса preempt_count() Возвратить значение счетчика преемптивности Более полное решение задачи работы с данными, связанными с определенным процессором, — это получение номера процессора (который используется в качестве индекса для доступа к данным, связанным с определенным процессором) с помощью функции get_cpu (). Эта функция запрещает преемптивность ядра перед тем, как возвратить номер текущего процессора.

int cpu = get_cpu()

;

/* работаем с данными, связанными с текущим процессором... */ /* работа закончена, снова разрешаем вытеснение кода ядра */ put_cpu()

;

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

Рассмотрим следующий код.

а = 1

;

Ь = 2

;

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

В большинстве случаев такая перестановка операций будет оптимальной, так как между переменными a и b нет никакой зависимости. Тем не менее иногда програм мисту все-таки виднее.

Хотя в предыдущем примере и может быть изменен порядок выполнения, ни процессор, ни компилятор никогда не будут менять порядок выполнения следующе го кода, где переменные а и b являются глобальными.

а = 1

;

b = а

;

Это происходит потому, что в последнем случае четко видно зависимость между переменными a и b. Однако ни компилятор, ни процессор не имеют никакой ин формации о коде, который выполняется в других контекстах. Часто важно, чтобы результаты записи в память "виделись" в нужном порядке другим кодом, который выполняется за пределами нашей досягаемости. Такая ситуация часто имеет место при работе с аппаратными устройствами, а также возникает на многопроцессорных машинах.

Функция rmb () позволяет установить барьер чтения памяти (read memory barrier).

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

Процессоры Intel х86 никогда не переопределяют порядок операций записи, Т.е. выполняют за пись всегда в указанном порядке. Тем не менее другие процессоры могут нести себя и по-другому, 202 Глава Функция wmb () позволяет установить барьер записи памяти (write barrier). Она работает так же, как и функция rmb (), но не с операциями чтения, а с операциями записи — гарантируется, что операции записи, которые находятся по разные сторо ны барьера, никогда не будут переставлены местами друг с другом.

Функция rnb () позволяет создать барьер на чтение и запись. Никакие операции чтения и записи, которые указаны по разные стороны вызова функции rab {), не бу дут переставлены местами друг с другом. Эта функция предоставляется пользовате лю, так как существует машинная инструкция (часто та же инструкция, что использу ется вызовом rmb ()), которая позволяет установить барьер на чтение и запись.

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

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

Для некоторых аппаратных платформ функция read_barrier_depends () вы полняется значительно быстрее, чем функция rmb (), так как для этих платформ функция read_barrier_depends () просто не нужна и вместо нее выполняется ин струкция nоор (нет операции).

Рассмотрим пример использования функций mb () и rmb (). Первоначальное зна чение переменной а равно 1, а переменной b равно 2 Поток 1 Поток а=3

;

mb()

;

b=4

;

c=b

;

rmb()

;

d=a

;

Без использования барьеров памяти для некоторых процессоров возможна ситу ация, в которой после выполнения этих фрагментов кода переменной с присвоится новое, значение переменной b, в то время как переменной d присвоится старое зна чение переменной а. Например, переменная с может стать равной 4 (что мы и хо тим), а переменная d может остаться равной 1 (чего мы не хотим). Использование функции mb () позволяет гарантировать, что переменные a и b записываются в ука занном порядке, а функция rmb () гарантирует, что чтение переменных b и а будет выполнено в указанном порядке.

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

Это может привести к тому, что инструкции чтения переменных b и а выполнятся не в том порядке. Функции rmb () и wmb () соответствуют инструкциям, которые за ставляют процессор выполнить все незаконченные операции чтения и записи перед тем, как продолжить работу далее.

Рассмотрим простой пример случая, когда можно использовать функцию read_ barrier_depends () вместо функции rmb(). В этом примере изначально перемен ная а равна 1, b - 2, а p - &b.

Средства синхронизации в ядре Поток 1 Поток а=3

;

mb()

;

p=&а

;

pp=р

;

read_barrier_depends()

;

b=*pp

;

Снова без использования барьеров памяти появляется возможность того, что переменной b будет присвоено значение *рр до того, как переменной рр будет при своено значение переменной р. Функция read_barrier_depends () обеспечивает достаточный барьер, так как считывание значения *рр зависит от считывания пере менной р. Здесь также будет достаточно использовать функцию rmb (), но посколь ку операции чтения зависимы между собой, то можно использовать потенциально более быструю функцию read_barrier_depends (). Заметим, что в обоих случаях требуется использовать функцию mb () для того, чтобы гарантировать необходимый порядок выполнения операций чтения-записи в потоке 1.

Макросы smp_rmb (), smp_wmb (), smp_mb() и smpread_barrier_depends () позволяют выполнить полезную оптимизацию. Для SMP-ядра они определены как обычные барьеры памяти, а для ядра, рассчитанного на однопроцессорную маши ну, — только как барьер компилятора. Эти SMP-варианты барьеров можно использо вать, когда ограничения на порядок выполнения операций являются специфичными для SMP-систем.

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

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

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

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

В табл. 9.10 приведен полный список функций установки барьеров памяти и ком пилятора, которые доступны для разных аппаратных платформ, поддерживаемых ядром Linux.

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

204 Глава Таблица 9.10. Средства установки барьеров компилятора и памяти Барьер Описание rmb() Предотвращает изменение порядка выполнения операций чте ния данных из памяти при переходе через барьер read_barrier_depends() Предотвращает изменение порядка выполнения операций чте ния данных из памяти при переходе через барьер, но только для операций чтения, которые зависимы друг от друга wtnb() Предотвращает изменение порядка выполнения операций за писи данных в память при переходе через барьер mb() Предотвращает изменение порядка выполнения операций чте ния и записи данных при переходе через барьер smp_rmb() Для SMP-ядер эквивалентно функции rmb(), а для ядер, рас считанных на однопроцессорные машины, эквивалентно функ ции barr i er ( ) smp_read_barrier_depends() Для SMP-ядер эквивалентно функции read_barrier_depends().

а для ядер, рассчитанных на однопроцессорные машины, экви валентно функции bar r i er ( ) srap_wmb() Для SMP-ядер эквивалентно функции wmb(), а для ядер, рас считанных на однопроцессорные машины, эквивалентно функ ции bar r i er ( ) smp_mb() Для SMP-ядер эквивалентно функции mb(), а для ядер, рас считанных на однопроцессорные машины, эквивалентно функ ции bar r i er ( ) barrier() Предотвращает оптимизации компилятора по чтению и записи данных при переходе через барьер Средства синхронизации в ядре Таймеры и управление временем тслеживание хода времени очень важно для ядра. Большое количество функ ций, которые выполняет ядро, управляются временем (time driven), в отличие О от тех функций, которые выполянются по событиям1 (event driven). Некоторые из этих функций выполняются периодически, как, например, балансировка очередей выполнения планировщика или обновление содержимого экрана. Такие функции вы зываются в соответствии с постоянным планом, например 100 раз в секунду. Другие функции, такие как отложенные дисковые операции ввода-выпода, ядро планирует на выполнение в некоторый относительный момент времени в будущем. Например, ядро может запланировать работу на выполнение в момент времени, который на ступит позже текущего на 500 миллисекунд. Наконец, ядро должно вычислять время работы системы (uptime), а также текущую дату и время.

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

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

Системный таймер — это программируемое аппаратное устройство, которое генери рует аппаратное прерывание с фиксированной частотой. Обработчик этого преры вания, который называется прерыванием таймера (timer interrupt), обновляет значение системного времени и выполняет периодические действия. Системный таймер и его прерывание являются важными для работы оператщонной системы Linux, и в теку щей главе им уделяется главное внимание.

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

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

Информация о времени в ядре Концепция времени для компьютера является несколько неопределенной. В дей ствительности, для того чтобы получать информацию о времени и управлять си стемным временем, ядро должно взаимодействовать с системным аппаратным обе спечением. Аппаратное обеспечение предоставляет системный таймер, который используется ядром для измерения времени. Системный таймер работает от элек тронного эталона времени, такого как цифровые электронные часы или тактовый генератор процессора. Интервал времени системного таймера периодически исте кает (еще говорят таймер срабатывает— hitting, popping) с определенной запрограм мированной частотой. Эта частота называется частотой импульсов таймлра, (tick rate).

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

Так как в ядре есть информация о запрограммированной частоте следования им пульсов таймера, ядро может вычислить интервал времени между двумя успешными прерываниями таймера. Этот интервал называется временной отметкой или импуль сом таймера (tick) и в секундах равен единице, деленной на частоту импульсов. Как будет показано дальше, именно таким способом ядро отслеживает абсолютное время (wall time) и время работы системы (uptime). Абсолютное время— это фактическое время дня, которое наиболее важно для пользовательских приложений. Ядро отслеживает это время просто потому, что оно контролирует прерывание таймера. В ядре есть семейство системных вызовов, которое позволяет пользовательским приложениям получать информацию о дате и времени дня. Это необходимо, так как многие про граммы должны иметь информацию о ходе времени. Разница между двумя значени ями времени работы системы — "сейчас" и "позже" — это простой способ измерения относительности событий.

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

• Обновление значения времени работы системы (uptime).

• Обновление значения абсолютного времени (time of day).

• Для SMP-систем выполняется проверка балансировки очередей выполнения планировщика, и если они не сбалансированы, то их необходимо сбалансиро вать (как было рассказано в главе 4, "Планирование выполнения процессов").

208 Глава • Проверка, не израсходовал ли текущий процесс свой квант времени, и если израсходовал, то выполнятся планирование выполнения нового процесса (как это было рассказано в главе 4).

• Выполнение обработчиков всех динамических таймеров, для которых истек период времени.

• Обновление статистики по использованию процессорного времени и других ресурсов.

Некоторые из этих действий выполняются при каждом прерывании таймера, т.е.

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

Частота импульсов таймера: HZ Частота системного таймера (частота импульсов, tick rate) программируется при загрузке системы на основании параметра ядра НZ, который определен с помощью директивы препроцессора. Значение параметра HZ отличается для различных под держиваемых аппаратных платформ. На самом деле, для некоторых аппаратных платформ значение параметра HZ отличается даже для разных типов машин.

Данный параметр ядра определен в файле. Частота системного таймера равна значению параметра HZ, период таймера равен 1/HZ. Например, в файле include/asm-i386/param.h для аппаратной платформы i386 этот параметр определен следующим образом.

#define HZ 1000 /* internal kernel time frequency */ Поэтому для аппаратной платформы i368 прерывание таймера генерируется с частотой 1000 Гц, т.е. 1000 раз в секунду (каждую тысячную долю секунды или одну миллисекунду). Для большинства других аппаратных платформ значение частоты системного таймера равно 100 Гц. В табл. 10.1 приведен полный список всех под держиваемых аппаратных платформ и определенных для них значений частоты си стемного таймера.

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

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

Таймеры и управление временем Таблица 10.1. Значение частоты системного таймера Аппаратная платформа Частота (в герцах) alpha arm cris h8300 i386 ia64 32 или m68k m68knommu 50, 100 или mips mips64 parisc 100 или ppc ppc64 s390 sti spare sparc64 um v850 24, 100 или x86-64 Идеальное значение параметра HZ Для аппаратной платформы i386, начиная с самых первых версий операционной системы Linux, значение частоты системного таймера было равно 100 Гц. Однако во время разработки ядер серии 2.5 это значение было увеличено до 1000 Гц, что (как всегда бывает в подобных ситуациях) вызвало споры. Так как в системе очень многое зависит от прерывания таймера, то изменение значения частоты системного таймера должно оказывать сильное влияние на систему. Конечно, как в случае боль ших, так и в случае маленьких значений параметра HZ есть свои положительные и отрицательные стороны.

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

• Прерывание таймера имеет большую разрешающую способность по времени, и следовательно, все событии, которые выполняются во времени, также имеют большую разрешающую способность.

• Увеличивается точность выполнения событий во времени.

Эмулятор платформы IA-64 имеет частоту 32 Гц. Настоящая машина платформы IA-64 имеет часто ту 1024 Гц.

••• 210 Глава Разрешающая способность увеличивается во столько же раз, во сколько раз воз растает частота импульсов. Например, гранулярность таймеров при частоте импуль сов 100 Гц равна 10 миллисекунд. Другими словами, все периодические события вы полняются прерыванием таймера, которое генерируется с предельной точностью по времени, равной 10 миллисекунд, и большая точность3 не гарантируется. При часто те, равной 1000 Гц, разрешающая способность равна 1 миллисекунде, т.е. в 10 раз выше. Хотя ядро позволяет создавать таймеры с временным разрешением, равным 1 миллисекунде, однако при частоте системного таймера в 100 Гц нет возможности гарантированно получить временной интервал, короче 10 миллисекунд.

Точность измерения времени также возрастает аналогичным образом. Допустим, что таймеры ядра запускаются в случайные моменты времени, тогда в среднем тай меры будут срабатывать с точностью по времени до половины периода прерывания таймера, потому что период времени таймера может закончиться в любой момент, а обработчик таймера может выполниться, только когда генерируется прерывание тай мера. Например, при частоте 100 Гц описанные события в среднем будут возникать с точностью +/- 5 миллисекунд от желаемого момента времени. Поэтому ошибка из мерения в среднем составит 5 миллисекунд. При частоте 1000 Гц ошибка измерения в среднем уменьшается до 0.5 миллисекунд — получает десятикратное улучшение.

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

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

• Системные вызовы, такие как poll () и select (), которые позволяют при же лании использовать время ожидания (timeout) в качестве параметра, выполня ются с большей точностью.

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

• Вытеснение процессов выполняется более правильно.

Некоторые из наиболее заметных улучшений производительности — это улуч шения точности измерения периодов времени ожидания при выполнении систем ных вызовов poll () и select (). Это улучшение может быть достаточно большим.

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

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

Таймеры и управление временем полняющегося процесса. Когда это значение уменьшается до нуля, устанавливается флаг need_resched, и ядро активизирует планировщик как только появляется та кая возможность. Теперь рассмотрим ситуацию, когда процесс в данный момент вы полняется и у него остался квант времени, равный 2 миллисекундам. Это означает, что через 2 миллисекунды планировщик должен вытеснить этот процесс и запустить на выполнение другой процесс. К сожалению, это событие не может произойти до того момента, пока не будет сгенерировано следующее прерывание таймера. В са мом худшем случае следующее прерывание таймера может возникнуть через 1/HZ секунд! В случае, когда параметр HZ=100, процесс может получить порядка 10 лиш них миллисекунд. Конечно, в конце концов все будет сбалансировано и равнодоступ ность ресурсов не нарушится, потому что все задания планируются с одинаковыми ошибками, и проблема состоит не в этом. Проблемы возникают из-за латентности, которую вносят задержки вытеснения процессов. Если задание, которое планирует ся на выполнение, должно выполнить какие-нибудь чувствительные ко времени дей ствия, как, например, заполнить буфер аудиоустройства, то задержка не допустима.

Увеличение частоты до 1000 Гц уменьшает задержку планировщика в худшем случае до 1 миллисекунды, а в среднем — до 0.5 миллисекунды.

Должна, однако, существовать и обратная сторона увеличения частоты систем ного таймера, иначе она была бы с самого начала равна 1000 Гц (или даже больше).

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

Проблема, связанная с накладными расходами, вызывает споры. Ясно, что переход от значения HZ=100 до значения HZ=1000 в 10 раз увеличивает накладные затраты, связанные с прерываниями таймера. Однако от какого реального значения наклад ных затрат следует отталкиваться? Если "ничего" умножить на 10, то получится тоже "ничего". Решающее соглашение состоит в том, что по крайней мере для современ ных систем, значение параметра HZ=1000 не приводит к недопустимым накладным затратам. Тем не менее для ядер серии 2.6 существует возможность скомпилировать ядро с другим значением параметра HZ.

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

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

В связи с ограничениями аппаратной платформы и протокола NTP, значение переменной HZ не может быть произвольным. Для платформы х86 значения 100, 500 и 1000 работают хорошо.

212 Глава Когда обработчик таймера сработает, создается новый таймер для следующего события и так повторяется постоянно. При таком подходе не требуется периодическое прерывание таймера и нет необходимости в параметре HZ.

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

Накладные расходы и сложность реализации получаются настолько высокими, что в операцион ной системе Linux такой подход решили не использовать. Тем не менее так пробовали делать, и результаты получаются интересными. Если интересно, то можно поискать в Интернет-архивах.

Переменная j i f f i es Глобальная переменная j i f f i e s содержит количество импульсов системного таймера, которые были получены со времени загрузки системы. При загрузке ядро устанавливает значение этого параметра в нуль и он увеличивается на единицу при каждом прерывании системного таймера. Так как в секунду возникает HZ прерыва ний системного таймера, то за секунду значение переменной j iffies увеличивается на HZ. Время работы системы (uptime) поэтому равно jiffies/HZ секунд.

Этимология слова jiffy Происхождение слова jiffy (миг, мгновение) точно неизвестно. Считается, что фразы типа "in a jiffy" (в одно мгновение) появились в Англии в восемнадцатом веке. В быту термин jiffy [миг) означает неопределенный, но очень короткий промежуток времени.

В научных приложениях слово jiffy используется для обозначения различных интервалов време ни (обычно порядка 10 ms). В физике это слово иногда используется для указания интервала времени, который требуется свету, чтобы пройти определенное расстояние (обычно, фут, сан тиметр, или расстояние, равное размеру нуклона).

В вычислительной технике термин jiffy — это обычно интервал времени между двумя соседними импульсами системного таймера, которые были успешно обработаны. В электричестве jiffy — период переменного тока. В США jiffy— это 1/60 секунды.

В приложении к операционным системам, в частности к Unix, jiffy— это интервал времени меж ду двумя соседними успешно обработанными импульсами системного таймера. Исторически это значение равно 100 ms. Как уже было показано, интервал времени jiffy в операционной си стеме Linux может иметь разные значения.

Переменная j iffies определена в файле следующим обра зом.

extern unsigned long volatile jiffies

;

Определение этой переменной достаточно специфичное, и оно будет рассмотре но более подробно в следующем разделе. Сейчас давайте рассмотрим пример кода ядра. Пересчет из секунд в значение переменной j i ffi es можно выполнить следу ющим образом.

(секунды * HZ) Таймеры и управление временем Отсюда следует, что преобразование из значения переменной j iffies в секунды можно выполнить, как показано ниже.

(jiffies / HZ) Первый вариант встречается более часто. Например, часто необходимо устано вить значение некоторого момента времени в будущем.

unsigned long time_starnp = jiffies

;

/* сейчас */ unsigned long next_tick = jiffies + 1

;

/* через один импульс таймера от текущего момента */ unsigned long later = jiffies + 5*HZ

;

/* через пять секунд от текущего момента */ Последний пример обычно используется при взаимодействии с пространством пользователя, так как в самом ядре редко используется абсолютное время.

Заметим, что переменная j iffies имеет тип unsigned long и использовать ка кой-либо другой тип будет неправильным.

Внутреннее представление переменной j i f f i es Переменная j i f f i es исторически всегда представлялась с помощью типа unsigned long и, следовательно, имеет длину 32 бит для 32-разрядных аппаратных платформ и 64 бит для 64-разрядных. В случае 32-разрядного значения переменной j iffies и частоты появления временных отметок 100 раз в секунду, переполнение этой переменной будет происходить примерно каждые 497 дней, что является впол не возможным событием. Увеличение значения параметра HZ до 1000 уменьшает пе риод переполнения до 47.9 дней! В случае 64-разрядного типа переменной jiffies, переполнение этой переменной невозможно за время существования чего-либо при любых возможных значениях параметра HZ для любой аппаратной платформы.

Из соображений производительности и по историческим причинам — в основ ном, для совместимости с уже существующим кодом ядра — разработчики ядра пред почли оставить тип переменной j iffies — unsigned long. Для решения проблемы пришлось немного подумать и применить возможности компоновщика.

Как уже говорилось, переменная jiffies определяется в следующем виде и имеет тип unsigned long.

extern unsigned long volatile jiffies

;

Вторая переменная определяется в файле в следующем виде.

extern u64 jiffies_64

;

Директивы компоновщика ld (1), которые используются для сборки главного об раза ядра (для аппаратной платформы х86 описаны в файле arch/i386/kernel/ vmlinux.lds.S), указывают компоновщику, что переменную j iffies необходимо совместить с началом переменной jiffies_64.

Jiffies = jiffies_64

;

Следовательно, переменная j i ffi es — это просто 32 младших разряда полной 64-разрядной переменной jiffies_64. Так как в большинстве случаев переменная 214 Глава j i f f i es используется для измерения промежутков времени, то для большей части кода существенными являются только младшие 32 бит.

В случае применения 64-разрядного значения, переполнение не может возник нуть за время существования чего-либо. В следующем разделе будут рассмотрены проблемы, связанные с переполнением (хотя переполнение счетчика импульсов си стемного таймера и не желательно, но это вполне нормальное и ожидаемое собы тие). Код, который используется для управления ходом времени, использует все бит, и это предотвращает возможность переполнения 64-разрядного значения. На рис. 10.1 показана структура переменных j i f f i es и j iffies_64.

Переменная j i f f i es_64 (и переменная j i f f i es на 64-разрядной машине) Переменная j iff ies на 32-разрядной машине Рис. 10.1. Структура переменных jiffies и jiffies_ Код, который использует переменную j i f f i es, просто получает доступ к трид цати двум младшим битам переменной j i ffi es_64. Функция get_j i ffi es_64 () может быть использована для получения полного 64-разрядного значения5. Такая не обходимость возникает редко, следовательно большая часть кода просто продолжает считывать младшие 32 разряда непосредственно из переменной j i f f i es.

На 64-разрядных аппаратных платформах переменные j i ffi es_64 и j i f f i es просто совпадают. Код может либо непосредственно считывать значение перемен ной j i f f i es, либо использовать функцию get_jiffies_64 (), так как оба этих спо соба позволяют получить аналогичный эффект.

Переполнение переменной j i f f i es Переменная j i f f i es, так же как и любое целое число языка программирования С, после достижения максимально возможного значения переполняется. Для 32-раз рядного беззнакового целого числа максимальное значение равно 232-1. Поэтому перед тем как счетчик импульсов системного таймера переполнится, должно прий ти 4294967295 импульсов таймера. Если значение счетчика равно этому значению и счетчик увеличивается на 1, то значение счетчика становится равным нулю.

Рассмотрим пример переполнения.

unsigned long timeout = j i ffi es + HZ/2

;

/* значение лимита времени равно 0.5 с */ Необходима специальная функция, так как на 32-разрядных аппаратных платформах нельзя ато марно обращаться к двум машинным словам 64-разрядного значения, Специальная функция, перед тем как считать значение, блокирует счетчик импульсов системного таймера с помощью блокиров ки xtime_lock.

Таймеры и управление временем /* выполним некоторые действия и проверим, не слишком ли это много заняло времени... */ if (timeout < jiffies) { /* мы превысили лимит времени — это ошибка... */ } else { /* мы не превысили лимит времени — это хорошо... */ } Назначение этого участка кода — установить лимит времени до наступления не которого события в будущем, а точнее полсекунды от текущего момента. Код может продолжить выполнение некоторой работы — возможно, записать некоторые дан ные в аппаратное устройство и ожидать ответа. После выполнения, если весь про цесс превысил лимит установленного времени, код соответственным образом обра батывает ошибку.

В данном примере может возникнуть несколько потенциальных проблем, свя занных с переполнением. Рассмотрим одну из них. Что произойдет, если перемен ная j iffies переполнится и снова начнет увеличиваться с нуля после того, как ей было присвоено значение переменной timeout? При этом условие гарантированно не выполнится, так как значение переменной j iffies будет меньше, чем значение переменной timeout, хотя логически оно должно быть больше. По идее значение переменной j iffies должно быть огромным числом, всегда большим значения пе ременной timeout. Так как эта переменная переполнилась, то теперь ее значение стало очень маленьким числом, которое, возможно, отличается от нуля на несколько импульсов таймера. Из-за переполнения результат выполнения оператора if меняет ся на противоположный!

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

#define time_after(unknown, known) ((long)(known) - (long)(unknown) < 0) #define time_before(unknown, known) ((long) (unknown) - (long)(known) < 0) #define time_after_eq(unknown, known) ((long) (unknown) - (long)(known) >= 0) #define time_before_eq(unknown, known) ((long) (known) - (long)(unknown) >= 0) Параметр unknown — это обычно значение переменной j i f f i es, а параметр known — значение, с которым его необходимо сравнить.

Макрос time_after (unknown, known) возвращает значение true, если момент времени unknown происходит после момента времени known, в противном случае возвращается значение false. Макрос time_before (unknown, known) возвраща ет значение true, если момент времени unknown происходит раньше, чем момент времени known, в противном случае возвращается значение false. Последние два макроса работают аналогично первым двум, за исключением того, что возвращается значение "истинно", если оба параметра равны друг другу.

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

unsigned long timeout = jiffies + HZ/2

;

/* значение лимита времени равно 0.5 с */ 216 Глава /* выполним некоторые действия и проверим, не слишком ли это много заняло времени... */ if (time_after(jiffies, timeout}) { /* мы превысили лимит времени — это ошибка... */ } else { /* мы не превысили лимит времени — это хорошо... */ } Если любопытно, каким образом эти макросы предотвращают ошибки, связан ные с переполнением, то попробуйте подставить различные значения параметров.

А затем представьте, что один из параметров переполнился, и посмотрите, что при этом произойдет.

Пространство пользователя и параметр HZ Раньше изменение параметра НZ приводило к аномалиям в пользовательских про граммах. Это происходило потому, что значения параметров, связанных со време нем, экспортировались в пространство пользователя в единицах, равных количеству импульсов системного таймера в секунду. Так как такой интерфейс использовался давно, то в пользовательских приложениях считалось, что параметр HZ имеет опре деленное конкретное значение. Следовательно, при изменении значения параметра HZ изменялись значения, которые экспортируются в пространство пользователя, в одинаковое число раз. Информация о том, во сколько раз изменились значения, в пространство пользователя не передавалась! Полученное от ядра значение времени работы системы могло интерпретироваться как 20 часов, хотя на самом деле оно равнялось только двум часам.

Чтобы исправить это, код ядра должен нормировать все значения переменной j i ffi es, которые экспортируются в пространство пользователя. Нормировка реа лизуется путем определения константы USER_HZ, равной значению параметра HZ, которое ожидается в пространстве пользователя. Та как для аппаратной платформы х86 значение параметра HZ исторически равно 100, то значение константы USER_ HZ=100. Макрос j iffies_to_clock_t() используется для нормировки значения счетчика импульсов системного таймера, выраженного в единицах HZ, в значение счетчика импульсов, выраженное в единицах USER_HZ. Используемый макрос зави сит от того, кратны ли значения параметров HZ и USER_HZ один другому. Если крат ны, то этот макрос имеет следующий очень простой вид.

#define jiffies_to_clock_t(x) ((х) / (HZ / USER_HZ)) Если не кратны, то используется более сложный алгоритм.

Функция jiffies_64_to_clock_t () используется для конвертирования 64-бито вого значения переменной j iffies из единиц HZ в единицы USER_HZ.

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

unsigned long start = jiffies

;

unsigned long total_time

;

/* выполнить некоторую работу... */ total_time = jiffies - start

;

printk("ЭTO заняло %lu импульсов таймера\n", jiffies_to_clock_t(total_time))

;

Таймеры и управление временем В пространстве пользователя передаваемое значение должно быть таким, ка ким оно было бы, если бы выполнялось равенство HZ=USER_HZ. Если это равенство не справедливо, то макрос выполнит нужную нормировку и все будут счастливы.

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

printk("Это заняло %lu секунд\n", total time / HZ)

;

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

Часы реального времени Часы реального времени (real-time clock, RTC) представляют собой энергонеза висимое устройство для сохранения системного времени. Устройство RTC продол жает отслеживать время, даже когда система отключена, благодаря небольшой бата рее, которая обычно находится на системной плате. Для аппаратной платформы PC устройство RTC интегриронано в КМОП-микросхему BIOS. При этом используется общая батарея и для работы устройства RTC и для сохранения установок BIOS.

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

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

Для аппаратной платформы х86 главный системный таймер — это программируе мый интервальный таймер (programmable interval timer, PIT). Таймер PIT существует 218 Глава на всех машинах платформы PC. Co времен операционной системы DOS он исполь зуется для управления прерываниями. Ядро программирует таймер PIT при загруз ке, для того чтобы периодически генерировать прерывание номер нуль с частотой HZ. Этот таймер— простое устройство с ограниченными возможностями, но, тем не менее, хорошо выполняющее свою работу. Другие эталоны времени для аппаратной платформы х86 включают таймер APIC (Advanced Programmable Interrupt Controller, расширенный программируемый контроллер прерываний) и счетчик отметок време ни (TSC, Time Stamp Counter).

Обработчик прерываний таймера Теперь, когда мы разобрались, что такое j i ffies и HZ, а также какова роль си стемного таймера, рассмотрим реализацию обработчика прерываний системного таймера. Обработчик прерываний таймера разбит на две части: часть, зависимую от аппаратной платформы, и независимую часть.

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

• Захватывается блокировка xtime_lock, которая защищает доступ к перемен ной jiffies_64 и значению текущего времени— переменной xtirne.

• Считывается или сбрасывается состояние системного таймера, если это необ ходимо.

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

• Вызывается аппаратно-независимая подпрограмма таймера do_timer ().

Аппаратно-независимая функция do_timer () выполняет значительно больше действий.

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

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

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

• Вызывается функция scheduler_tick (), как было рассмотрено в главе 4.

• Обновляется значение абсолютного времени, которое хранится в переменной xtime.

• Вычисляются значения печально известной средней загруженности системы (load average).

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

void do_timer(struct pt_regs *regs) { jiffies_64++

;

update_process_times(user_mode(regs))

;

update_times()

;

} Макрос user_mode () просматривает состояние регистров процессора, regs, и возвращает значение 1, если прерывание таймера возникло в пространстве пользо вателя, и значение 0— если в пространстве ядра. Это позволяет функции update_ process_times О учесть, что за время между предыдущим и данным импульсами системного таймера процесс выполнялся в режиме задачи или в режиме ядра.

void update_process_times(int user_tick) { struct task_struct *p = current

;

int cpu = smp_processor_id()

;

int system = user_tick ^ 1

;

update_one_process (p, user_tick, system, cpu)

;

run_local_timers()

;

scheduler_tick(user_tick, system)

;

} Функция update_process () собственно обновляет значения параметров вре мени выполнения процесса. Эта функция тщательно продумана. Следует обратить внимание, каким образом с помощью операции исключающее ИЛИ (XOR) достига ется, что одна из переменных user_ti ck и system имеет значение, равное нулю, а другая— единице. Поэтому в функции update_one_process () можно просто при бавить необходимое значение к соответствующим счетчикам без использования опе ратора ветвления.

/* * увеличиваем значения соответствующего счетчика импульсов таймера на единицу */ p->utime += user

;

p->stime += system

;

Необходимое значение увеличивается на 1, а другое остается без изменений.

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

Далее функция run_local_timers () помечает отложенные прерывания, как го товые к выполнению (см. главу 7, "Обработка нижних половин и отложенные дей 220 Главз ствия"), для выполнения всех таймеров, для которых закончился период времени ожидания. Таймеры будут рассмотрены ниже, в разделе "Таймеры".

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

После возврата из функции update_process_times () вызывается функция update_times (), которая обновляет значение абсолютного времени.

void update_times(void) { unsigned long ticks

;

ticks = jiffies - wall_jiffies

;

if (ticks) { wall_jiffies += ticks

;

update_wall_time(ticks)

;

} last_time_offset = 0

;

calc_load(ticks)

;

} Значение переменной ticks вычисляется как изменение количества импульсов системного таймера с момента последнего обновления абсолютного времени. В нор мальной ситуации это значение, конечно, равно 1. В редких случаях прерывание таймера может быть пропущено, и в таком случае говорят, что импульсы таймера потеряны. Это может произойти, если прерывания запрещены в течение длительно го времени. Такая ситуация не является нормальной и часто указывает на ошибку программного кода. Значение переменной wall_j iffies увеличивается на зна чение ticks, поэтому она равна значению переменной j i ffi es в момент самого последнего обновления абсолютного времени. Далее вызывается функция update_ wall_time () для того, чтобы обновить значение переменной xtime, которая со держит значение абсолютного времени. Наконец вызывается функция calc_load () для того, чтобы обновить значение средней загруженности системы, после чего функция update_times () возвращает управление.

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

Всё это происходит каждые 1/HZ секунд, т.е. 1000 раз в секунду на машине типа PC.

Абсолютное время Текущее значение абсолютного времени (time of day, wall time, время дня) опреде лено в файле kernel/timer.с следующим образом.

struct timespec xtime

;

Таймеры и управление временем Структура данных timespec определена в файле в следующем виде.

struct timespec { time_t tv_sec

;

/* seconds */ long tv_nsec

;

/* nanoseconds */ }

;

Поле xtime.tv_sec содержит количество секунд, которые прошли с 1 января 1970 года (UTC, Universal Coordinated Time, всеобщее скоординированное время).

Указанная дата называется epoch (начало эпохи). В большинстве Unix-подобных опе рационных систем счет времени ведется с начала эпохи. В поле xtime.tv_nsec хра нится количество наносекунд, которые прошли в последней секунде.

Чтение или запись переменной xtime требует захвата блокировки xtime_lock.

Это блокировка — не обычная спин-блокировка, а секвентпая блокировка, которая рассматривается в главе 9, "Средства синхронизации в ядре".

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

write_seqlock(&xtime_lock)

;

/* обновить значение переменной xtime... */ write_sequnlock(&xtime_lock)

;

Считывание значения переменной xtime требует применения функций read_ seqbegin() и read_seqretry () следующим образом.

do { unsigned long lost

;

seq = read_seqbegin(&xtime_lock)

;

usec = timer->get_offset()

;

lost = jiffies - wall_jiffies

;

if (lost) usec += lost * (1000000 / HZ)

;

sec = xtime.tv_sec

;

usec += (xtime.tv_nsec / 1000)

;

} while (read_seqretry(&xtime_lock, seq))

;

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

Главный пользовательский интерфейс для получения значения абсолютного вре мени — это системный вызов gettimeofday (), который реализован как функция sys_gettimeofday() следующим образом.

asmlinkage long sys_gettimeofday(struct timeval *tv, struct timezone *tz) { 222 Глава if (likely(tv !=NULL)) { struct timeval_ktv

;

do_gettimeofday(&ktv)

;

if (copy_to_userftv, &ktv, sizeof(ktv)) return -EFAULT

;

} if (unlikely(tz !=NULL)) { if (copy_to_user(tz, &sys_tz, sizeof(sys_tz))) return -EFAULT

;

} return 0

;

} Если из пространства пользователя передано ненулевое значение параметра tv, то вызывается аппаратно-зависимая функция do_gettimeofday(). Эта функция главным образом выполняет цикл считывания переменной xtime, который был только что рассмотрен. Аналогично, если параметр tz не равен нулю, пользователю возвращается значение часового пояса (time zone), в котором находится операцион ная система. Этот параметр хранится в переменной sys_tz. Если при копировании в пространство пользователя значения абсолютного времени или часового пояса возникли ошибки, то функция возвращает значение -EFAULT. В случае успеха воз вращается нулевое значение.

Ядро предоставляет системный вызов t i me(), однако системный вызов gettimeofday() полностью перекрывает его возможности. Библиотека функций языка С также предоставляет другие функции, связанные с абсолютным временем, такие как ftime() и ctirae().

Системный вызов settimeofday() позволяет установить абсолютное время в указанное значение. Для того чтобы его выполнить, процесс должен иметь возмож ность использования CAP_SYS_TIME.

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

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

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

Для некоторых аппаратных платформ функция sys_time () не реализована, а вместо этого она эмулируется библиотекой функций языка С на основании вызова gettimeofday ().

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

Использование таймеров Таймеры представлены с помощью структур timer l i st, которая определена в файле следующим образом.

struct tirner_list { struct list_head entry

;

/* таймеры хранятся в связанном списке */ unsigned long expires

;

/* время окончание срока ожидания в импульсах системного таймера (jiffies) */ spinlock_t lock

;

/* блокировка для защиты данного таймера */ void (*function) (unsigned long)

;

/*функция-обработчик таймера*/ unsigned long data

;

/* единственный аргумент обработчика */ struct tvec_t_base_s *base

;

/*внутренние данные таймера, не трогать! */ }

;

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

Первый шаг в создании таймера — это его объявление в следующем виде.

struct timer_list my_timer

;

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

init_timer(&my_timer)

;

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

my_timer.expires = j iffies + delay

;

/* интервал времени таймера закончится через delay импульсов */ Другая причина состоит в том, что в ядрах старых версий (до 2.3) существовали статические тай меры. Такие таймеры создавались во время компиляции, а не во время выполнения. Они имели ограниченные возможности и из-за их отсутствия сейчас никто не огорчается.

224 Глава my_timer.data = 0

;

/* в функцию-обработчик Судет передан параметр, равный нулю */ my_timer.function = my_function

;

/* функция, которая будет выполнена, когда интервал времени таймера истечет */ Значение поля my_ti mer. expi res указывает время ожидания в импульсах си стемного таймера (необходимо указывать абсолютное количество импульсов). Когда текущее значение переменной j i f f i es становится большим или равным значению поля my_timer. expi res, вызывается функция-обработчик my_timer.function с параметром my_timer.data. Как видно из описания структуры ti mer_l i st, функ ция-обработчик должна соответствовать следующему прототипу.

void my_timer_function(unsigned long data)

;

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

Последняя операция — это активизация таймера.

add_timer(&my_timer)

;

И таймер запускается! Следует обратить внимание на важность значения поля expired. Ядро выполняет обработчик, когда текущее значение счетчика импульсов системного таймера больше, чем указанное значение времени срабатывания таймера, или равно ему. Хотя ядро и гарантирует, что никакой обработчик таймера не будет выполняться до истечения срока ожидания таймера, тем не менее возможны задерж ки с выполнением обработчика таймера. Обычно обработчики таймеров выполня ются в момент времени, близкий к моменту времени срабатывания, однако они мо гут быть отложены и до следующего импульса системного таймера. Следовательно, таймеры нельзя использовать для работы в жестком режиме реального времени.

Иногда может потребоваться изменить момент времени срабатывания таймера, который уже активизирован. В ядре реализована функция mod_timer (), которая по зволяет изменить момент времени срабатывания активного таймера.

i mod_timer(&my_timer, jiffies + new_delay)

;

/* установка нового времени срабатывания */ Функция mod_timer () позволяет также работать с таймером, который проини циализирован, но не активен. Если таймер не активен, то функция mod_timer() активизирует его. Эта функция возвращает значение 0, если таймер был неактив ным, и значение 1, если таймер был активным. В любом случае перед возвратом из функции mod_timer () таймер будут активизирован, и его время срабатывания будет установлено в указанное значение.

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

del_timer(&my_timer)

;

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

При удалении таймеров потенциально может возникнуть состояние конкурен ции. Когда функция del_timer () возвращает управление, она гарантирует только то, что таймер будет неактивным (т.е. его обработчик не будет выполнен в будущем).

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

del_timer_sync (&my_timer)

;

В отличие от функции del_timer(), функция del_timer_sync() не может вы зываться из контекста прерывания.

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

del_timer (my_timer)

;

my_timer->expires = jiffies + new_delay

;

add_timer(my_timer)

;

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

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

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

void run_local_timers(void) { raise_softirq(TIMER_SOFTIRQ)

;

} Отложенное прерывание с номером TIMER_SOFTIRQ обрабатывается функцией run_tirner_softirq (). Эта функция выполняет на локальном процессоре обработчи ки всех таймеров, для которых истек период времени ожидания (если такие есть).

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

Следовательно, код управления таймерами очень эффективен.

Задержка выполнения Часто коду ядра (особенно драйверам) необходимо задерживать выполнение дей ствий на некоторый период времени без использования таймеров или механизма нижних половин. Это обычно необходимо для того, чтобы дать аппаратному обе спечению время на завершение выполнения задачи. Такой интервал времени обыч но достаточно короткий. Например, в спецификации сетевой интерфейсной платы может быть указано время изменения режима работы Ethernel-контроллера, равное 2 микросекундам, т.е. после установки желаемой скорости передачи драйвер должен ожидать хотя бы в течение двух микросекунд перед тем, как продолжить работу.

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

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

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

unsigned long delay = jiffies + 10

;

/* десять импульсов таймера */ while (time_before (jiffies, delay))

;

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

Таймеры и управление временем Цикл будет выполняться, пока значение переменной j i f f i es не станет больше, чем значение переменной delay, что может произойти только после того, как будут получены 10 импульсов системного таймера. Для аппаратной платформы х86 со зна чением параметра HZ, равным 1000, этот интервал равен 10 миллисекунд.

Аналогично можно поступить следующим образом.

unsigned long delay = jiffies + 2*HZ

;

/* две секунды */ while (time_before(jiffies, delay))

;

В этом случае цикл будет выполняться, пока не поступит 2*Н2 импульсов систем ного таймера, что всегда равно 2 секундам, независимо от частоты системного тай мера.

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

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

unsigned long delay = jiffies + 5*HZ

;

while (time_before(jiffies, delay)) cond_reschcd()

;

Вызов функции cond_resched() планирует выполнение другого процесса, но только в случае, если установлен флаг need_resched. Другими словами, данное ре шение позволяет активизировать планировщик, но только в случае, когда есть бо лее важное задание, которое нужно выполнить. Следует обратить внимание, что.

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

Поклонники языка С могут поинтересоваться, какие есть гарантии, что указан ные циклы будут действительно выполняться? Обычно компилятор С может выпол нить чтение указанной переменной всего один раз. В обычной ситуации нет никакой гарантии, что переменная j i f f i es будет считываться на каждой итерации цикла.

Нам же необходимо, чтобы значение переменной j i f f i es считывалось на каждой итерации цикла, так как это значение увеличивается в другом месте, а именно в пре рывании таймера. Именно поэтому данная переменная определена в файле с атрибутом vol at i l e. Ключевое слово vol at i l e указывает компиля тору, что эту переменную необходимо считывать из того места, где она хранится в оперативной памяти, и никогда не использовать копию, хранящуюся в регистре про цессора. Это гарантирует, что указанный цикл выполнится, как и ожидается.

228 Глава Короткие задержки Иногда коду ядра (и снопа обычно драйверам) необходимы задержки на очень ко роткие интервалы времени (короче, чем период системного таймера), причем интер вал должен отслеживаться с достаточно высокой точностью. Это часто необходимо для синхронизации с аппаратным обеспечением, для которого описано некоторое минимальное время выполнения действий, и которое часто бывает меньше одной миллисекунды. В случае таких малых значений времени невозможно использовать задержки на основании переменной j i f fi es, как показано в предыдущем примере.

При частоте системного таймера, равной 100 Гц, значение периода системного тай мера достаточно большое— 10 миллисекунд! Даже при частоте системного таймера 1000 Гц, период системного таймера равен одной миллисекунде. Ясно, что необходи мо другое решение, которое обеспечивает более короткие и точные задержки.

Ядро предоставляет две функции для обеспечения микросекундных и миллисе кундных задержек, которые определены в файле и не используют переменную j i f f i es.

void udelay(unsigned long usecs)

;

void mdelay(unsigned long msecs)

;

Первая функция позволяет задержать выполнение на указанное количество микросекунд с использованием цикла. Вторая функция задерживает выполнение на указанное количество миллисекунд. Следует вспомнить, что одна секунда равна миллисекундам, что эквивалентно 1000000 микросекунд. Использование этих функций тривиально.

udelay(150)

;

/* задержка на 150 ms */ Функция udelay () выполнена па основе цикла, для которого известно, сколько итераций необходимо выполнить за указанный период времени. Функция mdelay () выполнена на основе функции udelay (). Так как в ядре известно, сколько циклов процессор может выполнить в одну секунду (смотрите ниже замечание по поводу характеристики BogoMlPS), функция udelay () просто масштабирует это значение для того, чтобы скорректировать количество итераций цикла для получения указан ной задержки.

Мой BogoMIPS больше, чем у Вас!

Характеристика BogoMlPS всегда была источником недоразумений и шуток. На самом деле вы численное значение BogoMlPS не имеет ничего общего с производительностью компьютера и используется только для функций udel ay() и mdel ay(). Название этого параметра состоит из двух частей bogus (фиктивный) и MIPS (million of instructions per second, миллион инструкций в секунду). Все знакомы с сообщением, которое выдается при загрузке системы и похоже на следующее (данное сообщение соответствует процессору Pentium III с частотой 1 ГГц).

Detected 1004.932 MHz processor.

Calibrating delay loop... 1990.65 BogoMlPS Значение параметра BogoMIPS - это количество циклов, которые процессор может выполнить за указанный период времени, В действительности эта характеристика показывает, насколько быстро процессор может ничего не делать! Это значение хранится в переменной l oops_per_ j i f f y, и его можно считать из файла /proc/cpui nf o.

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

Ядро вычисляет значение переменной 1 oops_per_j i ffу при загрузке системы в функции cal i brate_del ay(), реализация которой описана в файле i ni t/mai n.c.

Функция udelay() должна вызываться только для небольших задержек, посколь ку при большом времени задержки на быстрой машине может возникнуть переполне ние в переменных цикла. Общее правило: по возможности не использовать функцию udelay() для задержек, больше одной миллисекунды. Для более продолжительных задержек хорошо работает функция mdelay(). Так же как и другие методы задерж ки выполнения, основанные на циклах, эти функции (особенно функция mdelay(), так как она дает длительные задержки) должны использоваться, только если это абсолютно необходимо. Следует помнить, что очень плохо использовать циклы за держек, когда удерживается блокировка или запрещены прерывания, потому что это очень сильно влияет на производительность и время реакции системы. Если необ ходимо обеспечить точное время задержки, то эти функции — наилучшее решение.

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

Функция schedule_timeout() Более оптимальный метод задержки выполнения — это использование функции schedule_timeouit (). Этот вызов переводит вызывающее задание в состояние ожи дания (sleep) по крайней до тех пор, пока не пройдет указанный период времени.

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

/* установить состояние задания в значение прерываемого ожидания */ set_current_state(TASK INTERRUPTIBLE)

;

/* перейти в приостановленное состояние на s секунд */ schedule_timeout(s * HZ)

;

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

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

Следует обратить внимание, что поскольку функция schedul e_tiraeout() ис пользует планировщик, то код, который ее вызывает, должен быть совместим с со стоянием ожидания. Обсуждение, посвященное атомарности и переходу в состояние 230 Глава ожидания, приведено в главах 8 и 9. Если коротко, то эту функцию необходимо вы зывать в контексте процесса и не удерживать при этом блокировку.

Функция schedule_tiraeout() достаточно проста. Она просто использует тайме ры ядра. Рассмотрим эту функцию подробнее.

signed long schedule_timeout(signed long timeout) { timer_t timer

;

unsigned long expire

;

switch (timeout) { case MAX_SCHEDULE_TIMEOUT:

schedule ()

;

goto out

;

default:

if (timeout < 0) { printk(KERN_ERR "schedule_timeout: wrong timeout " "value %lx from %p\n", timeout, builtin_return_address(0))

;

current->state = TASK_RUNNING

;

goto out

;

} } expire = timeout + jiffies

;

init timer(&timer)

;

timer.expires = expire

;

timer.data = (unsigned long) current

;

timer.function = process_timeout

;

add_timer(&timer)

;

schedule()

;

del_timer_sync(&timer)

;

timeout = expire - jiffies

;

out:

return timeout < 0 ? 0 : timeout

;

} Эта функция создает таймер timer и устанавливает время срабатывания в зна чение timeout импульсов системного таймера в будущем. В качестве обработчика таймера устанавливается функция process timeout (), которая вызывается, ког да истекает период времени таймера. Далее таймер активизируется, и вызывается функция schedule (). Так как предполагается, что текущее задание находится в со стоянии TASK_INTERRUPTIBLE или TASK_UNINTERRUPTIBLE, то планировщик не бу дет выполнять текущее задание, а выберет для выполнения другой процесс.

Когда интервал времени таймера истекает, то вызывается функция process_ timeout (), которая имеет следующий вид.

Таймеры и управление временем void process_timeout(unsigned long data) { wake_up_process((task t *) data)

;

} Эта функция устанавливает задание в состояние TASK_RUNNING и помещает его в очередь выполнения.

Когда задание снова планируется на выполнение, то оно возвращается в функцию schedule_tiraeout () (сразу после вызова функции schedule ()). Если задание воз вращается к выполнению преждевременно, то таймер ликвидируется. После этого задание возвращается из функции ожидания по тайм-ауту.

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

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

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

Время вышло В этой главе были рассмотрены понятия, связанные с представлением о времени в ядре и с тем, как при этом происходит управление абсолютным и относительным ходом времени. Были показаны отличия абсолютного и относительного времени, а также периодических и относительных событий. Далее были рассмотрены прерыва ния таймера, импульсы таймера, константа HZ и переменная j i f f i es.

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

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

232 Глава Управление памятью ыделить память внутри ядра не так просто, как вне ядра. Это связано со мно гими факторами. Главным образом, причина в том, что в ядре не доступны те В элементы роскоши, которыми можно пользоваться в пространстве пользователя, В отличие от пространства пользователя, в ядре не всегда можно позволить себе лег ко выделять память. Например, в режиме ядра часто нельзя переходить в состояние ожидания. Более того, в ядре не так просто справиться с ошибками, которые возни кают при работе с памятью. Из-за этих ограничений и из-за необходимости, чтобы схема выделения памяти была быстрой, работа с памятью в режиме ядра становится более сложной, чем в режиме пользователя. Конечно, нельзя сказать, что выделение памяти в ядре — очень сложная процедура, однако скоро все будет ясно — просто это делается несколько по-другому.

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

Страницы памяти Ядро рассматривает страницы физической памяти как основные единицы управ ления памятью. Хотя наименьшая единица памяти, которую может адресовать процессор, — это машинное слово, модуль управления памятью (MMU, Memory Management Unit) — аппаратное устройство, которое управляет памятью и отвечает за трансляцию виртуальных адресов в физические — обычно работает со страница ми. Поэтому модуль MMU управляет таблицами страниц на уровне страничной дета лизации (отсюда и название). С точки зрения виртуальной памяти, страница — это наименьшая значащая единица.

Как будет показано в главе 19, "Переносимость", каждая аппаратная платформа поддерживает свой характерный размер страницы. Многие аппаратные платформы поддерживают даже несколько разных размеров страниц. Большинство 32-разряд ных платформ имеют размер страницы, равный 4 Кбайт, а большинство 64-разряд ных платформ— 8 Кбайт. Это значит, что на машине, размер страницы которой ра вен 4 Кбайт, при объеме физической памяти, равном 1 Гбайт, эта физическая память разбивается на 262 144 страницы.

Ядро сопоставляет каждой странице физической памяти в системе структуру struct page. Эта структура определена в файле следующим образом.

struct page { page_flags_t flags

;

atomic_t _count

;

atornic_t _mapcount

;

unsigned long private

;

struct address_space *mapping

;

pgoff_t index

;

struct list_head lru

;

void *virtual

;

}

;

Рассмотрим самые важные поля этой структуры. Поле flags содержит состоя ние страницы. Это поле включает следующую информацию: является ли страни ца измененной (dirty) или заблокированной (locked) в памяти. Значение каждого флага представлено одним битом, поэтому всего может быть до 32 разных флагов.

Значения флагов определены в файле .

Поле _count содержит счетчик использования страницы — т.е. сколько на эту страницу имеется ссылок. Когда это значение равно нулю, это значит, что никто не использует страницу, и она становится доступной для использования при новом вы делении памяти. Код ядра не должен явно проверять значение этого поля, вместо этого необходимо использовать функцию page_count (), которая принимает ука затель на структуру page в качестве единственного параметра. Хотя в случае неза нятой страницы памяти значение счетчика _count может быть отрицательным (во внутреннем представлении), функция page_count () возвращает значение нуль для незанятой страницы памяти и положительное значение — для страницы, которая в данный момент используется. Страница может использоваться страничным кэшем (в таком случае ноле mapping указывает на объект типа address_space, который связан с данной страницей памяти), может использоваться в качестве частных дан ных (на которые в таком случае указывает поле private) или отображаться в табли цу страниц процесса.

Поле vi rt ual — это виртуальный адрес страницы. Обычно это просто адрес данной страницы в виртуальной памяти ядра. Некоторая часть памяти (называемая областью верхней памяти, high memory) не отображается в адресное пространство ядра (т.е. не входит в него постоянно). В этом случае значение данного поля равно NULL и страница при необходимости должна отображаться динамически. Верхняя память будет рассмотрена в одном из следующих разделов.

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

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

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

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

Разработчики часто удивляются, что для каждой физической страницы в системе создается экземпляр данной структуры. Они думают: "Как много для этого использу ется памяти!" Давайте посмотрим, насколько плохо (или хорошо) расходуется адрес ное пространство для хранения информации о страницах памяти. Размер структу ры st r uct page равен 40 байт. Допустим, что система имеет страницы размером 1 Кбайт, а объем физической памяти равен 128 Мбайт. Тогда все структуры раде в системе займут немного больше 1 Мбайт памяти — не очень большая плата за воз можность управления всеми страницами физической памяти.

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

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

• Некоторые аппаратные устройства могут выполнять прямой доступ к памяти (ПДП, DMA, Direct Memory Access) только в определенную область адресов.

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

В связи с этими ограничениями, в операционной системе Linux выделяют три зоны памяти.

• Z0NE_DMA. Содержит страницы, которые совместимы с режимом DMA.

• ZONE_NORMAL. Содержит страницы памяти, которые отображаются в адресные пространства обычным образом.

• ZONE_HIGHMEM. Содержит "верхнюю память", состоящую из страниц, которые не могут постоянно отображаться в адресное пространство ядра.

Эти зоны определяются в заголовочном файле .

То, как используется разделение памяти на зоны, зависит от аппаратной плат формы. Например, для некоторых аппаратных платформ нет проблем с прямым до ступом к памяти ни по какому адресу. Для таких платформ зона ZONE_DMA является пустой, и для всех типов выделения памяти используется зона ZONE_NORMAL.

Управление памятью Как противоположный пример можно привести платформу х86, для которой устройства ISA1 не могут выполнять операции DMA в полном 32-разрядном простран стве адресов, так как устройства ISA могут обращаться только к первым 16 Мбайт физической памяти. Следовательно, зона ZONE_DMA для платформы х8б содержит только страницы памяти с физическими адресами в диапазоне 0-16 Мбайт.

Аналогично используется и зона ZONE_HIGHMEM. To, что аппаратная платформа может отображать и чего она не может отображать в адресное пространство ядра, отличается для разных аппаратных платформ. Для платформы х86 зона ZONE_ HIGHMEM— это вся память, адреса которой лежат выше отметки 896 Мбайт. Для других аппаратных платформ зона ZONE_HIGHMEM пуста, так как вся память может непосредственно отображаться. Память, которая содержится в зоне ZONE_HIGHMEM, называется верхней памятью2 (high memory). Вся остальная память в системе называет ся нижней памятью (low memory).

Зона ZONE_NORMAL обычно содержит все, что не попало в две предыдущие зоны памяти. Для аппаратной платформы х86, например, зона ZONE_NORMAL содержит всю физическую память от 16 до 896 Мбайт. Для других, более удачных аппаратных платформ, SONE_NORMAL— это вся доступная память. В табл. 11.1 приведен список зон для аппаратной платформы х86.

Таблица 11.1. Зоны памяти для аппаратной платформы х Зона Описание физическая память ZONE_DMA Страницы памяти, совместимые с ПДП < 16 Мбайт ZONE_NORMAL Нормально адресуемые страницы 16 - 896 Мбайт ZONE_HIGHMEM Динамически отображаемые страницы > 896 Мбайт Операционная система разделяет страницы системной памяти на зоны, чтобы иметь пулы страниц для удовлетворения требований выделения памяти. Например, пул зоны ZONE_DMA дает возможность ядру удовлетворить запрос на выделение па мяти, которая необходима для операций DMA. Если нужна такая память, ядро может просто выделить необходимое количество страниц из зоны ZONE_DMA. Следует обра тить внимание, что зоны не связаны с аппаратным обеспечением— это логическое группирование, которое позволяет ядру вести учет страниц

;

памяти.

Хотя некоторые запросы на выделение памяти могут требовать страницы из определенной зоны, это требование не обязательно может быть жестким. Например, выделение памяти для ПДП требует страницы из зоны ZONE DMA, а для обычного выделения памяти могут подойти страницы как из зоны ZONE_NORMAL, так и из зоны ZONE_DMA. Конечно, для удовлетворения запросов по обычному выделению памяти ядро будет стараться выделять страницы из зоны ZONE_NORMAL, чтобы сохранить страницы в зоне ZONE_DMA для случая, когда эти страницы действительно нужны, Если же наступает решающий момент (становится недостаточно памяти), то ядро может обратиться к любой доступной и подходящей зоне.

Некоторые некачественные устройства PCI также могут выполнять прямой доступ к памяти толь ко к 24-битовом адресном пространстве. Но эти устройства работают не правильно.

Это не имеет ничего общего с верхней памятью в операционной системе DOS.

236 Глава Каждая зона представлена с помощью структуры struct zone, которая опреде лена в файле в следующем виде.

struct zone { spinlock t lock

;

unsigned ]ong free_pages

;

unsigned long pages_min

;

unsigned long pages_low

;

unsigned long pages_high

;

unsigned long protection[MAX_NR_ZONES]

;

spinlock_t lru_lock

;

struct list_head active_list

;

struct list_head inactive_list

;

unsigned long nr_scan_active

;

unsigned long nr_scan_inactive

;

unsigned long nr_active

;

unsigned long nr_inactive

;

int all_unreclaimable

;

unsigned long pages_scanned

;

int temp_priority

;

int prev_priority

;

struct free_area free_area[MAX_ORDER]

;

wait_queue_head_t *wait_table

;

unsigned long wait_table_size

;

unsigned long wait_table_bits

;

struct per_cpu_pageset pageset[NR_CPUS]

;

struct pglist_data *zone_pgdat

;

struct page *zone_mem_map

;

unsigned long zone_start_pfn

;

char *name

;

unsigned long spanned_pages

;

unsigned long prcsent_pages

;

}

;

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

Поле lock— это спин-блокировка, которая защищает структуру от параллельно го доступа. Обратите внимание, что она защищает только структуру, а не страницы, которые принадлежат зоне. Для защиты отдельных страниц нет блокировок, хотя отдельные части кода могут блокировать данные, которые могут оказаться в указан ных страницах.

Поле free_pages — это количество свободных страниц в соответствующей зоне.

Ядро старается поддерживать свободными хотя бы pages_min страниц зоны, если это возможно (например, с помощью вытеснения на диск).

Поле name— это строка, оканчивающаяся нулем, которая содержит имя соответ ствующей зоны (что не удивительно). Ядро инициализирует указанное поле при за грузке системы с помощью кода, который описан п файле mm/page_alloc.с. Три зоны имеют имена "DMA", "Normal" и "HighMem".

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

struct page * alloc_pages(unsigned int gfp_mask, unsigned int order) Данная функция позволяет выделить 2or der (т.е. 1 << order) смежных страниц (один непрерывный участок) физической памяти и возвращает указатель на структу ру page, которая соответствует первой выделенной странице памяти. В случае ошиб ки возвращается значение NULL. Параметр gfp_mask будет рассмотрен несколько позже. Полученную страницу памяти можно конвертировать в ее логический адрес с помощью следующей функции.

void * page_address(struct page *page) Эта функция возвращает указатель на логический адрес, которому в данный мо мент соответствует начало указанной страницы физической памяти. Если нет необ ходимости в соответствующей структуре st ruct page, то можно использовать сле дующую функцию.

unsigned long get_free_pages(unsigned int gfp_mask, unsigned int order) Эта функция работает так же, как и функция al l oc_pages (), за исключением того, что она сразу возвращает логический адрес первой выделенной страницы па мяти. Так как выделяются смежные страницы памяти, то другие страницы просто следуют за первой.

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

struct page * alloc_page(unsigned int gfp_mask) unsigned long get_free_page(unsigned int gfp_mask) Эти функции работают так же, как и ранее описанные, по для них в качестве па раметра order передается нуль (20 = одна страница памяти).

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

unsigned long get_zeroed_page(unsigned int gfp_mask) Эта функция аналогична функции get_free_page (), за исключением того, что после выделения страницы памяти она заполняется нулями. Это полезно для страниц памяти, которые возвращаются в пространство пользователя, так как слу 238 Глава чайный "мусор", который находится в страницах памяти, может оказаться не совсем случайным и случайно может содержать некоторые (например, секретные) данные.

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

Таблица 11.2. Низкоуровневые средства выделения памяти Функция Описание al l oc_page (gfp_mask) Выделяет одну страницу памяти и возвращает указа тель на соответствующую ей структуру page o r d e r alloc_pages (gfp_mask, order) Выделяет 2 страниц памяти и возвращает указа тель на структуру page первой страницы get_free_page (gfp_mask) Выделяет одну страницу памяти и возвращает указа тель на ее логический адрес o r de r get_free_pages (gfp_mask, order) Выделяет 2 страниц памяти и возвращает указа тель на логический адрес первой страницы get_zeroed_page (gfp_mask) Выделяет одну страницу памяти, обнуляет ее содержи мое и возвращает указатель на ее логический адрес Освобождение страниц Для освобождения страниц, которые больше не нужны, можно использовать сле дующие функции.

void free_pages(struct page *page, unsigned int order) void free_pages(unsigned long addr, unsigned int order) void free_page(unsigned long addr) Необходимо быть внимательными и освобождать только те страницы памяти, ко торые вам выделены. Передача неправильного значения параметра page, addr или order может привести к порче данных. Следует помнить, что ядро доверяет себе.

В отличие от пространства пользователя, ядро с удовольствием зависнет, если вы по просите. Рассмотрим пример. Мы хотим выделить 8 страниц памяти.

page = get_free_pages(GFP_KERNEL, 3)

;

if (!page) { /* недостаточно памяти: эту ошибку необходимо обработать самим! */ return -ENOMEM

;

} /* переменная 'page' теперь содержит адрес первой из восьми страниц памяти*/ free_pages(page, 3)

;

/* * наши страницы памяти теперь освобождены и нам больше нельзя * обращаться по адресу, который хранится в переменной 'page' */ Управление памятью Значение GFP_KERNEL, которое передается в качестве параметра, — это пример флага gfp_mask, который скоро будет рассмотрен детально.

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

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

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

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

Рассматриваемая функция определена в файле следующим об разом.

void * kmalloc(size_t size, int flags) Данная функция возвращает указатель на участок памяти, который имеет размер хотя бы size байт3. Выделенный участок памяти содержит физически смежные стра ницы. В случае ошибки функция возвращает значение NULL. Выделение памяти в ядре заканчивается успешно, только если доступно достаточное количество памяти.

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

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

struct dog *ptr

;

ptr = kmalloc (sizeof (struct dog), GFP_KERNEL)

;

if (!ptr) /* здесь обработать ошибку... */ Данная функция может выделить памяти больше, чем указано, и нет никакой возможности узнать, на сколько больше! Поскольку в своей основе система выделения памяти в ядре базируется на страницах, некоторые запросы на выделение памяти могут округляться, чтобы хорошо вписывать ся е области доступной памяти. Ядро никогда не выделит меньше памяти, чем необходимо. Если ядро не v, состоянии найти хотя бы указанное количество байтов, то операция завершится неудач но и функции возвратит значение NULL.

240 Глава Если вызов функции kmalloc () завершится успешно, то переменная ptr будет указывать на область памяти, размер которой больше указанного значения или ра вен ему. Флаг GFP_KERNEL определяет тип поведения системы выделения памяти, когда она пытается выделить необходимую память при вызове функции kmalloc ().

Флаги gfp_mask Выше были показаны различные примеры использования флагов, которые моди фицируют работу системы выделения памяти, как при вызове низкоуровневых функ ций, работающих на уровне страниц, так и при использовании функции kmalloc {).

Теперь давайте рассмотрим их более детально.

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

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

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

Описанные модификаторы можно указывать вместе, как показано в следующем примере.

ptr = kmalioc(size, GFP_WAIT | GFP_IO | GFP_FS)

;

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

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

Управление памятью Таблица 11.3. Модификаторы операций Флаг Описание GFP_WAIT Операция выделения памяти может переводить текущий процесс в состояние ожидания GFP_HIGH Операция выделения памяти может обращаться к аварийным запасам Операция выделения памяти может использовать дисковые операции GFP_IO ввода-вывода Операция выделения памяти может использовать операции ввода GFP_FS вывода файловой системы Операция выделения памяти должна использовать страницы памяти, GFP_COLD содержимое которых не находится в кэше процессора (cache cold) Операция выделения памяти не будет печатать сообщения об ошибках GFP_NOWARN Операция выделения памяти повторит попытку выделения в случае ошибки GFP_REPEAT Операция выделения памяти будет повторять попытки выделения неопределенное количество раз GFP_NOFAIL Операция выделения памяти никогда не будет повторять попытку выделения памяти GFP_NORETRY Используется внутри слябового распределителя памяти (slab layer) GFP_NO_GROW Добавить метаданные составной (compound) страницы памяти.

Используется кодом поддержки больших страниц памяти (hugetlb) GFP_COMP Модификаторы зоны Модификаторы зоны указывают, из какой зоны должна выделяться память. Обыч но выделение может происходить из любой зоны. Однако ядро предпочитает зону ZONE_NORMAL, чтобы гарантировать, что в других зонах, когда это необходимо, есть свободные страницы.

Существует всего два модификатора зоны, поскольку, кроме зоны ZONE_N0RMAL (из которой по умолчанию идет выделение памяти), существует всего две зоны.

В табл. 11.4 приведен список модификаторов зоны.

Таблица 11.4. Модификаторы зоны Флаг Описание GFP_DMA Выделять память только из зоны ZONE_ DMA GFP_HIGHMEM Выделять память только из зон ZONE_HIGHMEM и ZONE_NORMAL Указание одного из этих флагов изменяет зону, из которой ядро пытается выде лить память. Флаг GFP_DMA требует, чтобы ядро выделило память только из зоны ZONE_DMA. Этот флаг эквивалентен следующему высказыванию в форме жесткого требования: "Мне абсолютно необходима память, в которой можно выполнять операции прямого доступа к памяти". Флаг GFP_HIGHMEM, наоборот, требует, чтобы выделе ние памяти было из зон ZONE_NORMAL и ZOHE_HIGHMEM (вторая более предпочти тельна). Этот флаг эквивалентен запросу: "Я могу использовать верхнюю память, но мне на самом деле, все равно, и делайте, что хотите, обычная память тоже подойдет".

242 Глава Если не указан ни один из флагов, то ядро пытается выделять память из зон ZONE_NORMAL и ZONE_DMA, отдавая значительное предпочтение зоне ZONE_NORMAL.

Флаг GFP_HIGHMEM нельзя укалывать при вызове функций get_free_pages () или kmalloc (>. Это связано с тем, что они возвращают логический адрес, а не структуру page, и появляется возможность, что эти функции выделят память, кото рая в данный момент не отображается п виртуальное адресное пространство ядра и поэтому не имеет логического адреса. Только функция alloc_pagea () может вы делять страницы в верхней памяти. Однако в большинстве случаев в запросах на вы деление памяти не нужно указывать модификаторы зоны, так как достаточно того, что используется зона ZONE_NORMAL.

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

В табл. 11.5 приведен список возможных флагов типов, а в табл. 11.6 показано, какие модификаторы соответствуют какому флагу.

Таблица 11.5. Флаги типов Флаг Описание GFP_ATOMI C Запрос на выделение памяти высокоприоритетный и в состояние ожидания переходить нельзя. Этот флаг предназначен для использования в обработчиках прерываний, нижних половин и в других ситуациях, когда нельзя переходить в состояние ожидания GFP_NOI O Запрос на выделение памяти может блокироваться, но при его выполнении нельзя выполнять операции дискового ввода-вывода. Этот флаг предназначен для использования в коде блочного ввода-вывода, когда нельзя инициировать новые операции ввода-вывода GFP_NOFS Запрос на выделение памяти может блокироваться и выполнять дисковые опе рации ввода-вывода, но запрещено выполнять операции, связанные с файло выми системами. Этот флаг предназначен для использования в коде файловых систем, когда нельзя начинать выполнение новых файловых операций GFP_KERNEL Обычный запрос на выделение памяти, который может блокироваться. Этот флаг предназначен для использования в коде, который выполняется в контек сте процесса, когда безопасно переходить в состояние ожидания GFP_USER Обычный запрос на выделение памяти, который может блокироваться. Этот флаг используется для выделения памяти процессам пространства пользователя GFP_HIGHUSER Запрос на выделение памяти из зоны ZONE_HIGHMEM, который может блоки роваться. Этот флаг используется для выделения памяти процессам простран ства пользователя GFP_DMA Запрос на выделение памяти из зоны ZONE_DMA. Драйверам устройств, кото рым нужна память для выполнения операций по ПДП, необходимо использо вать этот флаг обычно в комбинации с одним из описанных выше флагов Управление памятью Таблица 11.6. Список модификаторов, соответствующих каждому флагу типа Флаг Модификаторы GFP_ATOMIC GFP_HIGH GFP_NOIO GFP_WAIT GFP_NOFS (GFP_WAIT | GFP_IO) GFP_KERNEL (GFP_WAIT | GFP_IO | GFP_FS) GFP_USER (GFP_WAIT | GFP_IO | GFP_FS) GFP_HIGHUSER (GFP_WAIT | GFP_IO | GFP_FS | GFP_HIGHMEM) GFP_DMA GFP_DMA Рассмотрим наиболее часто используемые флаги и для чего они могут быть нуж ны. Подавляющее большинство операций выделения памяти в ядре используют флаг GFP_KERNEL. В результате операция выделения памяти имеет обычный приоритет и может переводить процесс в состояние ожидания. Поскольку этот вызов может бло кироваться, его можно использовать только в контексте процесса, выполнение ко торого может быть безопасно перепланировано (т.е. нет удерживаемых блокировок и т.д.). При использовании этого флага нет никаких оговорок по поводу того, каким образом ядро может получить необходимую память, поэтому операция выделения памяти имеет большой шанс выполниться успешно.

Можно сказать, что свойства флага GFP_ATOMIC лежат на противоположном кон це спектра. Так как этот флаг указывает, что операция выделения памяти не может переходить в состояние ожидания, то такая операция очень ограничена в том, ка кую память можно использовать для выделения. Если нет доступного участка памя ти заданного размера, то ядро, скорее всего, не будет пытаться освободить память, поскольку вызывающий код не может переходить в состояние ожидания. При ис пользовании флага GFP_KERNEL, наоборот, ядро может перевести вызывающий код в состояние ожидания, чтобы во время ожидания вытеснить страницы на диск (swap out), очистить измененные страницы памяти путем записи их в дисковый файл (flush dirty pages) и т.д. Поскольку при использовании флага GFP_ATOMIC нет возможности выполнить ни одну из этих операций, то и шансов успешно выполнить выделение памяти тоже меньше (по крайней мере, когда в системе недостаточно памяти). Тем не менее использование флага GFP_ATOMIC— это единственная возможность, когда вызывающий код не может переходить в состояние ожидания, как в случае обработ чиков прерываний и нижних половин.

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

Выделение памяти с флагом GFP_NOIO не будет запускать никаких операций дис кового ввода-вывода. С другой стороны, при использовании флага GFP_NOFS могут запускаться операции дискового ввода-вывода, но не могут запускаться операции файловых систем. Когда эти флаги могут быть полезны? Они соответственно необ ходимы для определенного низкоуровневого кода блочного ввода-вывода или кода файловых систем. Представьте себе, что в некотором часто используемом участке кода файловых систем используется выделение памяти без указания флага GFP_NOFS.

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

Флаг GFP_DMA применяется для указания, что система выделения памяти долж на при выполнении запроса предоставить память из зоны ZONE_DMA. Этот флаг ис пользуется драйверами устройств, для которых необходимо выполнение операций прямого доступа к памяти. Обычно этот флаг должен комбинироваться с флагами CFP_ATOMIC или GFP_KERNEL.

В подавляющем большинстве случаев при разработке кода вам будет необходимо использовать флаги GFP_ATOMIC или GFP_KERNEL. В табл. 11.7 показано какие флаги и в каких ситуациях необходимо использовать. Независимо от типа операции выде ления памяти, необходимо проверять результат и обрабатывать ошибки.

Таблица 11.7. Какой флаг и когда необходимо использовать Ситуация Решение Контекст процесса, можно переходить в со- Используется флаг GFP_KERNEL стояние ожидания Контекст процесса, нельзя переходить в со- Используется флаг GFP_ATOMIC или память вы стояние ожидания деляется с использованием флага GFP_KERNEL но в более ранний или поздний момент, когда можно переходить в состояние ожидания Обработчик прерывания Используется флаг GFP_ATOMIC Обработка нижней половины Используется флаг GFP_ATOMIC Необходима память для выполнения операций Используются флаги ПДП, можно переходить в состояние ожидания (GFP_DMA | GFP_KERNEL) Необходима память для выполнения операций Используются флаги (GFP_DMA | GFP_ATOMIC) ПДП, нельзя переходить в состояние ожидания или выделение выполняется в более поздний или более ранний момент времени Функция kfree() Обратной к функции kmalloc () является функция kfree (), которая определена в файле следующим образом.

void kfree(const void *ptr) Функция kfree () позволяет освободить память, ранее выделенную с помощью функции kmalloc (). Вызов этой функции для памяти, которая ранее не была выде лена с помощью функции kmalloc () или уже была освобождена, приводит к очень плохим последствиям, таким как освобождение памяти, которая принадлежит другим частям ядра. Так же как и в пространстве пользователя, количество операций выде ления памяти должно быть равно количеству операций освобождения, чтобы предот вратить утечку памяти и другие проблемы. Следует обратить внимание, что случай вызова kfree (NULL) специально проверяется и поэтому является безопасным.

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

char *buf

;

buf = kmalloc(BUF_SIZE, GFP_ATOMIC)

;

if (!buf) /* ошибка выделения памяти! */ Позже, когда память больше не нужна, нужно не забыть освободить ее с помо щью вызова функции kfree(buf)

;

Функция vmalloc () Функция vmalloc () работает аналогично функции kmalloc (), за исключением того, что она выделяет страницы памяти, которые только виртуально смежные и необязательно смежные физически. Точно так же работают и функции выделения памяти в пространстве пользователя: страницы памяти, которые выделяются с по мощью функции malloc (), япляются смежными в виртуальном адресном простран стве процесса, но нет никакой гарантии, что они смежные в физической оператив ной памяти. Функция kmalloc () отличается тем, что гарантирует, что страницы памяти будут физически (и виртуально) смежными. Функция vmalloc () гарантирует только, что страницы будут смежными в виртуальном адресном пространстве ядра.

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

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

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

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.