Настройка расширений ядра для поддержки DLPAR

Как и приложения, расширения ядра по умолчанию допускают DLPAR.

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

Регистрация обработчиков перенастройки

Для регистрации и отмены регистрации обработчиков перенастройки предусмотрены следующие службы:

#include sys/dr.h

int reconfig_register(int (*handler)(void *, void *, int, dr_info_t *),
                      int actions, void * h_arg, ulong *h_token, char *name);

void reconfig_unregister(ulong h_token);


int (*handler)(void *event, void *h_arg, unsigned long long req, void *resource_info);

void reconfig_unregister(ulong h_token);


int reconfig_register_ext (int (*handler)(void *, void *, unsigned long long, dr_info_t *),
unsigned long long actions, void * h_arg, ulong *h_token, char *name);

int (*handler)(void *event, void *h_arg, unsigned long long req, void *resource_info);


kerrno_t reconfig_register_list(int (*handler)(void *, void *, dr_kevent_t, void *), 
dr_kevent_t event_list[], size_t list_size, void *h_arg, ulong *h_token, char *name);

int (*handler)(void *event, void *h_arg, dr_kevent_t event_in_prog, void *resource_info);

Прим.: Можно использовать службу ядра reconfig_register_list. Эта служба поддерживает извещение расширений ядра о большем числе событий. Прежние службы ядра reconfig_register и reconfig_register_ext) ограничены 32 и 64 событиями, соответственно. Это не позволяет перенести расширения ядра, использующие данную службу, в более поздние системы, поддерживающие больше 32 и 64 событий.

Функции reconfig_register, reconfig_register_ext и reconfig_register_list имеют следующие параметры:

Параметр handler - это вызываемая функция расширения ядра.
Параметр actions позволяет указать, для каких событий требуется уведомление. Список событий приведен в описании служб ядра reconfig_register, reconfig_register_ext и reconfig_unregister.
Параметр h_arg указывается расширением ядра, хранится вместе с дескриптором функции и передается обработчику при его вызове. Он не используется ядром напрямую, но позволяет поддерживать расширения ядра, управляющие несколькими экземплярами адаптера. Фактически этот параметр указывает на блок управления адаптером.
Выходной параметр h_token используется при отмене регистрации обработчика.
Информационный параметр name может быть включен в сообщение об ошибке драйвера. Он указывается расширением ядра и должен содержать не более 15 символов ASCII.
Параметр event_list является массивом значений dr_kevent_t, для событий, уведомления о которых должны быть направлены расширению ядра. Список определенных событий приведен в описании службы ядра reconfig_register_list.
Параметр list_size - это объем памяти, необходимый для параметра event_list.

Функции reconfig_register и reconfig_register_ext возвращают 0 при успешном завершении и соответствующее значение errno - в случае ошибки.

Функция reconfig_unregister удаляет установленный ранее обработчик.

Функции reconfig_register, reconfig_register_ext и reconfig_unregister можно вызывать только в среде процесса.

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

Обработчики перенастройки

Обработчик перенастройки, используемый со службой ядра reconfig_register_list, имеет следующий интерфейс:

Int (*handler)(void *event, void *h_arg, dr_kevent_t event_in_prog, void *resource_info);

Обработчик перенастройки имеет следующие параметры:

Параметр event передается обработчику для использования при вызове функции reconfig_handler_complete.
Параметр h_arg указывается обработчиком при регистрации.
Параметр event_in_prog указывает операцию DLPAR, выполняемую обработчиком. Список событий приведен в описании службы ядра reconfig_register_list.
Параметр resource_info задает информацию о ресурсе для текущего запроса DLPAR. Если запрос основывается на процессе, то данные resource_info передаются через структуру dri_cpu. Если процесс основывается на памяти, применяется структура dri_mem. В разделе Создание микроразделов, если запрос основан на емкости процессора, данные resource_info предоставляются посредством структуры dri_cpu_capacity. Дополнительная информация о структуре dri_cpu_capacity и о ее формате приведена в разделе Служба ядра reconfig.

struct dri_cpu {
        cpu_t           lcpu;           /* ИД логического или целевого CPU */
        cpu_t           bcpu;           /* ИД связывания целевого CPU        */
};

struct dri_mem {
        size64_t        req_memsz_change;   /* запрошенный пользователем объем памяти */
        size64_t        sys_memsz;          /* начальный объем памяти системы */
        size64_t        act_memsz_change;   /* удаленная или добавленная память */
        rpn64_t         sys_free_frames;    /* число свободных кадров */
        rpn64_t         sys_pinnable_frames;/* число закрепляемых кадров */
        rpn64_t         sys_total_frames;   /* общее число кадров */
        unsigned long long lmb_addr;        /* начальный адрес логического блока памяти */
        size64_t        lmb_size;           /* размер добавляемого логического блока памяти */
};

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

Обработчики перенастройки вызываются в среде процесса.

Для расширений ядра применимы следующие ограничения:

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

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

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

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

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

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

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

Расширения ядра можно также уведомить об удалениях или добавлениях памяти при каждой операции (в значительной степени, подобно приложениям), зарегистрировав один или несколько типов извещений _OP_. Это позволяет расширению ядра модифицировать использование ресурсов в ответ на операцию DR с памятью один раз для каждой операции, а не для каждого логического блока памяти (LMB).

Уведомление DR_MEM_REMOVE_OP_PRE отправляется перед удалением памяти. Обработчики перенастройки могут начать регулировку своих ресурсов в ожидании удаления памяти. Уведомления DR_MEM_REMOVE_OP_POST и DR_MEM_ADD_OP_POST отправляются после операций удаления или добавления памяти соответственно, независимо от того, была ли операция выполнена успешно. В случае сбоя операции act_memsz_change равно 0.

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

Расширенные обработчики DR

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

void reconfig_handler_complete(void *event, int rc);

Параметр event был передан обработчику при вызове. Параметр rc должен быть равен либо DR_SUCCESS при успешном завершении, либо DR_FAIL при сбое.

Службу ядра reconfig_handler_complete можно вызывать в среде процесса или прерывания.

Применение службы ядра xmemdma

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

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

Если инициатор планирует применять адрес физической памяти для фактического доступа к данным путем выключения преобразования данных и использования функций доступа к физической памяти CPU вида загрузить/сохранить, либо путем создания контроллеров прямого доступа к памяти (DMA) для работы с физической памятью, то флаг XMEM_DR_SAFE указывать не нужно. При наличии такого флага операция динамического удаления памяти может привести к нарушению целостности данных системы. Информацию о преобразовании расширений ядра, использующих физическую память описанным способом, в версию, поддерживающую DLPAR, можно получить в сервисном представительстве IBM®.

Более подробные сведения по этому вопросу приведены в описании службы ядра xmemdma.

Управление уведомлением приложений об операциях над памятью DLPAR

Динамическое добавление и удаление памяти логических разделов, в которых работают программы с поддержкой DLPAR, может привести к конфликтам ресурсов. По умолчанию каждая программа получает уведомления об изменениях ресурсов. Например, удаление 1 Гб памяти из раздела, в котором выполняются две программы, поддерживающие DR, приведет к отправке каждой из этих программ соответствующего уведомления. Поскольку программы работают независимо друг от друга, то каждая из них уменьшит объем доступной памяти на 1 Гб, что приведет к снижению эффективности. Аналогичная неполадка может возникнуть при добавлении памяти.

Для того чтобы избежать этой неполадки AIX разрешает установку сценариев, вычисляющих коэффициент, указывающий на процентную долю фактического изменения памяти. Система уведомляет приложение в случае выполнения операции DLPAR по изменению памяти. Данный коэффициент можно указать с помощью пары DR_MEM_PERCENT имя=значение в ходе установки сценария с помощью команды drmgr. Эта пара имя=значение применяется при вызове сценария с помощью команды drmgr scriptinfo. Допустимы целые значения в диапазоне от 1 до 100. Остальные значения игнорируются и вместо них указывается значение по умолчанию 100. Кроме того, данную пару имя=значение можно указать в качестве переменной среды в процессе установки. В этом случае значение переменной среды, если оно задано, переопределяет значение, указанное сценарием.

Аналогичным образом при работе с приложениями, использующими обработчик сигналов SIGRECONFIG и системный вызов dr_reconfig(), вы можете управлять уведомлениями об операциях DLPAR по изменению памяти, указав пару DR_MEM_PERCENT имя=значение в качестве переменной среды. Обратите внимание, что для изменения этого значения требуется перезапуск приложения.