Prise en compte des extensions de noyau DLPAR

Comme les applications, la plupart des extensions de noyau sont DLPAR-safe par défaut.

Toutefois, certains sont sensibles à la configuration du système et peuvent avoir besoin d'être enregistrés auprès du sous-système DLPAR . Certaines extensions de noyau partitionnent leurs données le long des lignes de processeur, créent des unités d'exécution en fonction du nombre de processeurs en ligne ou fournissent des pools de mémoire tampon réservés volumineux. Ces extensions de noyau doivent être notifiées lorsque la topologie du système change. Le mécanisme et les actions à effectuer sont parallèles à ceux des applications DLPAR.

Enregistrement des gestionnaires de reconfiguration

#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);

Les fonctions reconfig_register et reconfig_register_ext renvoient 0 en cas de réussite, et la valeur errno appropriée dans le cas contraire.

La fonction reconfig_unregister est appelée pour supprimer un gestionnaire précédemment installé.

Les fonctions reconfig_register, reconfig_register_extet reconfig_unregister ne peuvent être appelées que dans l'environnement de processus.

Si une extension de noyau s'enregistre pour la pré-phase, il est conseillé de l'enregistrer pour la phase de vérification afin d'éviter une annulation partielle de la configuration du système lors de la suppression de ressources.

Gestionnaires de reconfiguration

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

struct dri_cpu {
        cpu_t           lcpu;           /* Logical CPU Id of target CPU */
        cpu_t           bcpu;           /* Bind Id of target CPU        */
};

struct dri_mem {
        size64_t        req_memsz_change;   /* user requested mem size  */
        size64_t        sys_memsz;          /* system mem size at start */
        size64_t        act_memsz_change;   /* mem added/removed so far */
        rpn64_t         sys_free_frames;    /* Number of free frames */
        rpn64_t         sys_pinnable_frames;/* Number of pinnable frames */
        rpn64_t         sys_total_frames;   /* Total number of frames */
        unsigned long long lmb_addr;        /* start addr of logical memory block */
        size64_t        lmb_size;           /* Size of logical memory block being added */
};

Si la demande DLPAR en cours est la migration d'une partition, le gestionnaire fournit des données resource_info aux extensions de noyau de données resource_info , mais les extensions du noyau n'ont pas besoin d'accéder au contenu des données resource_info car ces données ne sont pas utilisées par les extensions du noyau.

Les gestionnaires de reconfiguration sont appelés dans l'environnement de processus.

La phase de vérification permet aux applications DLPARet aux extensions de noyau de réagir à la demande de l'utilisateur avant qu'elle ne soit appliquée. Par conséquent, le gestionnaire d'extension de noyau de phase de vérification est appelé une seule fois, même si la demande peut être transférée à plusieurs blocs de mémoire logique. Contrairement à la phase de contrôle, les phases de pré-phase, de post-phase et de post-erreur sont appliquées au niveau du bloc de mémoire logique. Ceci est différent pour la notification d'application, où la phase de pré-phase, de post-phase ou encore la phase de post-erreur sont appelées une fois pour chaque requête utilisateur, quel que soit le nombre de blocs de mémoire logique sous-jacents. Une autre différence est que la phase de post-erreur pour les extensions de noyau est utilisée lorsqu'une opération de bloc de mémoire logique spécifique échoue, tandis que la phase de post-erreur pour les applications est utilisée lorsque l'opération, qui dans ce cas est la demande de l'utilisateur entier, échoue.

En général, lors de la phase de vérification, l'extension de noyau examine son état pour déterminer si elle peut être conforme à la demande DLPAR imminente. Si cette opération ne peut pas être gérée ou si elle a un effet négatif sur l'exécution correcte de l'extension, le gestionnaire renvoie DR_FAIL. Sinon, le gestionnaire renvoie DR_SUCCESS.

Lors de la phase de pré-suppression, les extensions de noyau tentent de supprimer les dépendances qu'elles peuvent avoir sur la ressource désignée. Par exemple, il s'agit d'un pilote qui gère des pools de mémoire tampon par processeur. Le pilote peut marquer le pool de mémoire tampon associé comme étant en attente de suppression, de sorte que de nouvelles demandes ne soient pas allouées à partir de ce pool. Dans le temps, le pool est vidé et peut être libéré. Les autres éléments qui doivent être pris en compte dans la phase de pré-suppression sont les temporisateurs et les unités d'exécution liées, qui doivent être arrêtés et arrêtés, respectivement. Les unités d'exécution liées peuvent également être non liées.

Au cours de la phase de post-suppression, les extensions de noyau tentent de libérer des ressources via la récupération de place, en supposant que la ressource a été effectivement supprimée. Si ce n'est pas le cas, les temporisateurs et les unités d'exécution doivent être rétablis. La demande DR_resource_POST_ERROR est utilisée pour indiquer qu'une erreur s'est produite.

Lors de la phase de pré-ajout, les extensions de noyau doivent pré-initialiser tous les chemins de données qui dépendent de la nouvelle ressource, de sorte que lorsque la nouvelle ressource est configurée, elle soit prête à être utilisée. Le système ne garantit pas que la ressource ne sera pas utilisée avant que le gestionnaire ne soit à nouveau appelé lors de la phase postérieure.

Lors de la phase de post-ajout, les extensions de noyau peuvent supposer que la ressource a été correctement ajoutée et peut être utilisée. Cette phase est un endroit pratique pour démarrer des unités d'exécution liées, planifier des temporisateurs et augmenter la taille des mémoires tampon.

Les extensions de noyau peuvent également être notifiées des suppressions ou des ajouts de mémoire par opération, tout comme les applications, en s'enregistrant pour un ou plusieurs types de notification _OP_ . Cela permet à une extension de noyau de modifier son utilisation des ressources en réponse à une opération de reprise après incident de la mémoire une seule fois par opération, plutôt qu'une fois par bloc de mémoire logique (LMB).

La notification DR_MEM_REMOVE_OP_PRE est envoyée avant un retrait de mémoire. Les gestionnaires de reconfiguration peuvent commencer à ajuster leurs ressources en prévision du retrait de la mémoire à ce moment-là. Les notifications DR_MEM_REMOVE_OP_POST et DR_MEM_ADD_OP_POST sont envoyées après une opération de suppression ou d'ajout de mémoire, respectivement, que l'opération ait échoué ou non. Si l'opération a échoué, act_memsz_change est 0.

Si possible, dans un délai de quelques secondes, les gestionnaires de reconfiguration renvoient DR_SUCCESS pour indiquer que la reconfiguration a abouti ou DR_FAIL pour indiquer l'échec. Si plus de temps est nécessaire, le gestionnaire renvoie DR_WAIT.

Gestionnaires de reprise après incident étendus

void reconfig_handler_complete(void *event, int rc);

Le paramètre event est le même que celui qui a été transmis au gestionnaire lorsqu'il a été appelé par le noyau. Le paramètre rc doit être défini sur DR_SUCCESS ou sur DR_FAIL pour indiquer l'état d'achèvement du gestionnaire.

Le service de noyau reconfig_handler_complete peut être appelé dans les environnements de processus ou d'interruption.

Utilisation du service de noyau xmemdma

Sur les systèmes compatibles avec DLPAR, tels que la suppression dynamique de la mémoire, les appels au service de noyau xmemdma sans l'indicateur XMEM_DR_SAFE entraînent le marquage de la mémoire spécifiée comme non amovible. Ceci est fait pour garantir l'intégrité du système, car le système n'a aucune connaissance de la façon dont l'appelant a l'intention d'utiliser l'adresse mémoire réelle qui a été renvoyée. Les opérations de retrait de mémoire dynamique sont toujours possibles pour une autre mémoire, mais pas pour la mémoire spécifiée par l'appel xmemdma .

Si l'appelant utilise l'adresse de la mémoire réelle uniquement à des fins d'information, par exemple pour les tampons de trace ou les informations de débogage, il peut définir l'indicateur XMEM_DR_SAFE . Ceci indique au système que l'adresse de la mémoire réelle peut être exposée à l'appelant sans risque de corruption de données. Lorsque cet indicateur est présent, le système autorise toujours la suppression dynamique de la mémoire spécifiée.

Si l'appelant utilise l'adresse de la mémoire réelle pour effectuer un accès réel aux données, soit en désactivant la traduction des données et en effectuant la charge de l'UC ou en stockant l'accès à la mémoire réelle, soit en programmant des contrôleurs d'accès direct à la mémoire (DMA) pour cibler la mémoire réelle, l'indicateur XMEM_DR_SAFE ne doit pas être défini. Si l'indicateur est défini, l'intégrité des données du système peut être compromise lorsque la mémoire est supprimée de manière dynamique. Pour plus d'informations sur la conversion d'une extension de noyau qui utilise des adresses de mémoire réelle de cette manière afin d'être compatible avec DLPAR, contactez votre représentant IBM

Pour plus d'informations, voir le service de noyau xmemdma .

Contrôle de la notification DLPAR de mémoire pour les applications

L'ajout ou le retrait dynamique de la mémoire d'une partition logique exécutant plusieurs programmes DLPAR peut entraîner un conflit de ressources. Par défaut, chaque programme est informé de manière égale de la modification de la ressource. Par exemple, si 1 Go de mémoire est supprimé d'une partition logique exécutant deux programmes prenant en charge la reprise après incident, chaque programme est notifié par défaut que 1 Go de mémoire a été supprimé. Comme les deux programmes ne sont généralement pas conscients l'un de l'autre, ils réduiront leur utilisation de la mémoire de 1 Go, ce qui entraîne une inefficacité. Un problème d'efficacité similaire peut également se produire lors de l'ajout d'une nouvelle mémoire.

Pour résoudre ce problème, AIX permet d'installer des scripts d'application avec un facteur de pourcentage qui indique le pourcentage de changement réel de la ressource mémoire. Le système avertit ensuite l'application dans le cas d'une mémoire DLPAR. Lors de l'installation des scripts d'application à l'aide de la commande drmgr , vous pouvez spécifier ce facteur de pourcentage à l'aide de la paire DR_MEM_PERCENT name=value . Le script d'application doit générer cette paire nom=valeur lorsqu'il est appelé par la commande drmgr avec la sous-commande scriptinfo . La valeur doit être un entier compris entre 1 et 100. Toute valeur en dehors de cette plage est ignorée et la valeur par défaut, 100, est utilisée. En outre, vous pouvez également définir cette paire name=value en tant que variable d'environnement au moment de l'installation. Lors de l'installation, la valeur de la variable d'environnement, si elle est définie, remplace la valeur fournie par le script d'application.

De même, dans les applications utilisant le gestionnaire de signaux SIGRECONFIG et l'appel système dr_reconfig () , vous pouvez contrôler la notification DLPAR de mémoire en définissant la paire DR_MEM_PERCENT name=value comme variable d'environnement avant que l'application ne commence à s'exécuter. Toutefois, cette valeur ne peut pas être modifiée sans redémarrer l'application.