FR 2767938 A1 19990305 FR 9711025 A 19970904 1 2767938 PROCEDE D'ALLOCATION DE MEMOIRE DANS UN SYSTEME DE TRAITEMENT DE L'INFORMATION MULTIPROCESSEUR La présente invention concerne un procédé d'allocation de mémoire dans un système de traitement de l'information multiprocesseur, plus particulièrement un procédé d'allocation d'une mémoire à accès non uniforme. Dans le cadre de l'invention, le terme "non uniforme" s'entend dans un sens temporel, comme il va l'être montré. De même, le terme "une mémoire" s'entend dans un sens général.10 Il peut signifier une mémoire distribuée, une hiérarchie de mémoire (par exemple comprenant des bancs de mémoires à temps d'accès différents), ou un ensemble de mémoires de types différents. Comme il est bien connu dans le domaine informatique, il est possible d'augmenter la puissance d'une machine en augmentant le nombre de processeurs dont elle est composée. Un type de machine connu sous le nom "SMP" (de l'anglo-saxon "Symetrical MultiProcessor" ou multiprocesseur Symétrique) permet aux différents processeurs d'une même machine d'accéder de façon symétrique à sa mémoire au moyen d'un bus système. Ce sont des machines avec mémoire à accès uniforme dans la mesure o le temps d'accès à la mémoire est sensiblement le même pour toutes les données accédées. Pour cette raison, l'architecture est dite "UMA" (de l'anglo-saxon "Uniform Memory Access" ou accès uniforme à la mémoire). La figure 1 annexée à la présente description illustre schématiquement un exemple d'architecture du type "UMA". Le système de traitement de l'information 1, que l'on appellera ci- après module "SMP", comprend un certain nombre d'unités centrales ou processeurs ou encore "CPU" selon la 2 2767938 terminologie anglo-saxonne. On a représenté quatre unités centrales dans l'exemple de la figure 1: 10 à 13. On associe à ces unités centrales 10 à 13, une mémoire centrale 14 accessible par tous. Puisque tous les accès s'effectuent à l'intérieur du module 1, c'est-àdire en local, et si l'espace mémoire total disponible présente une homogénéité quant au temps d'accès (ce qui constitue l'hypothèse de départ, puisqu'il s'agit d'une architecture "UMA"), le temps d'accès reste sensiblement le même, quelle que soit l'unité centrale 10 à 13, qui effectue une requête. Bien que, sur la figure 1, il ait été représenté quatre unités centrales 10 à 13, il doit être clair que ce nombre est tout à fait arbitraire. Il peut être augmenté ou15 diminué. Cependant, la courbe de performances de telles machines ne croît pas de façon linéaire en fonction du nombre de processeurs. Un nombre élevé de processeurs fait que le système consomme plus de temps pour des problèmes d'accessibilité à ses ressources qu'il n'en dispose pour20 exécuter des applications. Ceci a pour conséquence d'infléchir considérablement la courbe de performances lorsque le nombre de processeurs dépasse une valeur optimale souvent estimée à quatre environ. L'état de la technique propose différentes solutions à ce problème. Une solution connue consiste à regrouper en grappes plusieurs machines de façon à les faire communiquer entre elles au moyen d'un réseau. Chaque machine possède un nombre optimal de processeurs, par exemple quatre, et son propre système d'exploitation. Elle établit une communication avec30 une autre machine toutes les fois qu'elle effectue un traitement sur des données détenues à jour par cette autre machine. Le temps nécessaire à ces communications et la nécessité de travailler sur des données cohérentes posent des problèmes de latence pour des applications volumineuses35 telles que, par exemple, les applications réparties qui 3 2767938 demandent de nombreuses communications. La latence est la durée qui sépare l'instant d'émission d'une requête d'accès à la mémoire et l'instant auquel la réponse à cette requête est reçue. Une autre solution connue est celle des machines à architecture de type dit "NUMA" (de l'anglo-saxon "Non Uniform Memory Access"). Ce sont des machines avec mémoire à accès non uniforme, dans la mesure o le temps d'accès à la mémoire varie selon la localisation des données accédées. Une10 machine de type "NUMA" est constituée de plusieurs modules, chaque module comprenant un nombre optimal de processeurs et une partie physique de la mémoire totale de la machine. Une telle machine est à accès mémoire non uniforme car un module accède généralement plus facilement et plus rapidement à une15 partie physique de la mémoire qu'il ne partage pas avec un autre module qu'à une partie qu'il partage. Bien que chaque module possède un bus système privé reliant ses processeurs et sa mémoire physique, un système d'exploitation commun à tous les modules permet de considérer l'ensemble des bus20 systèmes privés comme un seul et unique bus système de la machine. Un adressage logique affecte un lieu de résidence à un emplacement de mémoire physique déterminé d'un module. Pour un processeur considéré, on distingue les accès à une partie de mémoire locale, située physiquement sur le même25 module que le processeur, et les accès à une partie de mémoire distante, située physiquement sur un ou plusieurs autres modules que celui o est situé le processeur. La figure 2 annexée à la présente description illustre schématiquement un exemple d'architecture de ce type, c'est-àdire une architecture "NUMA". Pour simplifier le dessin, on a supposé que le système de traitement de l'information 1' comprend seulement deux modules, Ma et Mb, du type "SMP" précité, et que les deux modules étaient identiques. Il doit cependant être bien compris que le système de traitement de l'information 1' peut comporter un 4 2767938 plus grand nombre de modules et que les modules Ma et Mb, peuvent être différents (notamment en ce qui concerne le nombre d'unités centrales). Le module Ma comprend donc quatre unités centrales 10a à 13a, et une mémoire centrale 14a. De même, le module Mb comprend quatre unités centrales 10b à 13b, et une mémoire centrale 14b. Les deux mémoires 14a et 14b, (et de façon plus générale les n mémoires centrales) communiquent entre elles à l'aide de ce qui est appelé un "lien" 2, généralement via des10 antémémoires (dites memory cache en anglais) dites éloignées a et 15b, respectivement. Le lien 2 ne se résume pas à de simples liaisons physiques mais comprend des circuits électroniques divers classiques (circuits de commande, d'interface, etc.), qu'il est inutile de décrire plus avant. On comprend aisément que, dans une telle architecture, si une application s'exécute dans le module Ma, par exemple, le temps d'accès à la mémoire "proche" 14a (accès en local) est, a priori, inférieur au temps d'accès à la mémoire "éloignée" 14b située dans le module Mb, ce quelle que soit l'unité centrale 10a à 13a, concernée. Il est notamment nécessaire de passer par le lien 2, lorsque les données sont physiquement stockées dans un autre module, ce qui augmente sensiblement le temps de transfert. Dans les systèmes de traitement de l'information modernes, l'allocation de la mémoire pour une application donnée s'effectue sur la base d'un espace mémoire virtuel. Cette allocation est placée sous la commande du système d'exploitation ou "OS" (de l'anglo-saxon "Operating System"). On effectue ensuite une correspondance dynamique entre30 l'espace mémoire virtuel et la mémoire physique. Pour ce faire, on utilise classiquement des tables de correspondance d'adresses. On parle de "mapping" dynamique, selon l'expression anglo-saxonne couramment utilisée. Différents types de configurations de mémoires ont été proposés: organisation par régions ou par segments. Pour fixer les 2767938 idées, dans ce qui suit, sans en limiter en quoi que ce soit la portée de l'invention, on se placera dans le cas d'une configuration du type "segment". De façon plus précise, dans l'art connu, la correspondance dynamique précitée ou "mapping" s'effectue selon des règles communes à toutes les applications quels qu'en soient leurs types, sans tenir compte de la localisation de la mémoire physique. De façon pratique, si un processus veut accéder à une adresse virtuelle et qu'aucune10 entrée dans la table de correspondance d'adresses n'est trouvée, il y a génération d'une exception qui se formalise par la détection d'un défaut de page. Le terme "page" peut être défini de façon plus générale comme étant une "plage d'adresses contiguës". Cependant, pour des raisons de simplification, le terme "page" sera utilisé dans ce qui suit. Un dispositif appelé gestionnaire attribue alors de la mémoire physique suite à cette détection, ce selon les règles communes précitées. Cette méthode d'allocation simple est tout à fait adaptée pour les machines classiques "SMP" du20 type "UMA" précité, puisque le temps moyen d'accès à la mémoire est uniforme. Par contre, lorsqu'il s'agit d'une architecture du type "NUMA", telle que décrite en regard de la figure 2, pour laquelle le temps d'accès n'est plus uniforme, le besoin se25 fait sentir de disposer d'un procédé d'allocation de mémoire qui minimise l'impact négatif sur les performances du système. Dans l'art connu, des procédés ont été proposés en ce sens. A titre d'exemple, on a proposé de modifier les règles d'allocation de mémoire en vue d'obtenir une optimisation, mais les règles une fois modifiées restent identiques pour toutes les applications. En outre, ce procédé présente des inconvénients supplémentaires. Les règles modifiées peuvent s'avérer avantageuses pour une application donnée, mais35 inappropriées, voire dangereuses pour une autre. On a 6 2767938 également proposé des "API" particuliers (de l'anglo-saxon "Application programmable Interface" ou interface programmable pour application) adaptées pour définir un algorithme particulier associé à une application donnée, en5 vue d'effectuer la correspondance ("mapping") entre l'espace mémoire virtuel et la mémoire physique, mais il est alors nécessaire de modifier, à la fois, les applications correspondantes et la partie résidente du système d'exploitation ("kernel"). Cette méthode ne peut donc pas10 s'appliquer, notamment, aux programmes existants. En tout état de cause, elle manque de souplesse et son efficacité est limitée. L'invention se fixe donc pour objet un procédé d'allocation de mémoire pour un système de traitement de l'information à accès non uniforme de la mémoire centrale, notamment du type "NUMA" précité, qui vise à répondre aux besoins qui se font sentir pour cette architecture particulière et qui ne présentent pas les inconvénients des procédés de l'art connu. En particulier, il n'est pas20 nécessaire de modifier les applications existantes. Pour ce faire, l'allocation de mémoire s'effectue en fonction du profil propre à chaque application, c'est-à-dire en mettant en oeuvre un jeu de règles d'allocation tenant compte de ce profil. Dans un mode de réalisation préféré, l'allocation de mémoire s'effectue en outre en tenant compte du type de défaut de page. En effet, lors de son exécution, une application se subdivise en différents objets tels que du texte, des données, de la mémoire partagée, etc., qui30 utilisent l'espace global de mémoire du système différemment. L'invention permet donc d'optimiser également les accès mémoire en fonction de ce paramètre. L'invention a donc pour objet un procédé d'allocation d'emplacements de mémoire physique par mise en correspondance 7 2767938 avec au moins une plage d'adresses contiguës de mémoire dans un espace d'adressage virtuel associée à une application logicielle déterminée, l'application étant en cours d'exécution dans un système de traitement de l'information5 comprenant une unité de mémoire à accès non uniforme et utilisant plusieurs types de mémoire virtuelle, ladite mise en correspondance s'effectuant par scrutation d'une table de correspondance d'adresses, caractérisé en ce qu'il comprend une étape consistant à lier ladite application logicielle10 déterminée à des règles d'allocation de mémoire choisies parmi un jeu de règles prédéfinies, et en ce que, lorsque ladite table de correspondance d'adresses ne comporte pas d'entrée pour une plage d'adresses contiguës de mémoire d'adresse virtuelle associée à ladite application logicielle15 déterminée, il comprend une étape de génération d'une exception et une étape subséquente d'allocation d'un emplacement de mémoire physique selon une desdites règles d'allocation de mémoire, le choix de la règle étant assujetti a un profil desdits types de mémoire virtuelle utilisés par20 l'application logicielle déterminée. L'invention sera mieux comprise et d'autres caractéristiques et avantages apparaîtront à la lecture de la description qui suit en référence aux figures annexées, parmi lesquelles: - la figure 1 illustre schématiquement une architecture de système de traitement de l'information à accès de mémoire uniforme dite "UMA"; - la figure 2 illustre schématiquement une architecture de système de traitement de l'information à accès de mémoire non uniforme dite "NUMA"; les figures 3a et 3b illustrent schématiquement les accès à la mémoire pour deux exemples d'applications logicielles; - la figure 4 illustre un exemple de subdivision d'une application logicielle; - la figure 5 illustre schématiquement l'allocation d'un emplacement de mémoire selon l'art connu, lors de la génération d'un défaut de page; - et les figures 6a et 6b illustrent schématiquement l'allocation d'un emplacement de mémoire selon l'invention, lors de la génération d'un défaut de page. Pour fixer les idées, sans en limiter en quoi que ce soit la portée, on se placera dans le contexte d'un système de traitement de l'information dont le système d'exploitation10 est du type "UNIX" (marque déposée) ou similaire, sauf mention contraire. Pour les applications fonctionnant sous cet environnement, l'espace d'adressage virtuel peut être divisé en différents types et notamment les types suivants: - le texte ou le texte programme (code exécutable) - les données initialisées; - les données modifiées; - les "stacks" ou piles; le "heap", c'est-à-dire l'allocation dynamique (tables, etc.); - la mémoire partagée; - les bibliothèques partagées. Lors du déroulement d'une application, celle-ci utilise les différents types de mémoire du système également de façon différente. L'ensemble des types de mémoire virtuelle utilisés définit un profil propre à l'application. En outre, une application ou une nouvelle instance de la même application peut s'exécuter dans l'un ou l'autre des modules Ma ou Mb, du système de la figure 2. Ce qui est vrai pour une30 même application, l'est encore plus pour deux applications de profils différents. 9 2767938 Les figures 3a et 3b illustrent schématiquement deux types d'applications, à savoir une "mini-base de données" ("minidatabase") et une base de données plus traditionnelle. On a représenté sur ces deux figures la mémoire globale du système par la référence unique Mem. Dans le premier cas, illustré par la figure 3a, lors d'une période d'initialisation, les accès sont cantonnés à un espace d'adressage représenté symboliquement par la zone Zini, située arbitrairement sur la gauche de la figure 3a.10 Puis, les accès s'effectuent dans un espace d'adressage, symbolisé par une zone Zf, également d'étendue restreinte et supposée connexe à la zone Zini, dans l'exemple décrit sur la figure 3a. Les emplacements de mémoire physique, pour cette application particulière, peuvent donc être cantonnés dans un15 seul module, et plus précisément en local. Ce n'est généralement pas le cas pour une base de données classique, comme illustré par la figure 3b. Les accès peuvent s'étendre à tout l'espace mémoire, comme le symbolisent les flèches représentées sur la figure 3b. Il20 s'ensuit que les emplacements de la mémoire physique occupée sont généralement distribués sur deux modules ou plus. En outre, comme il a été indiqué, pour une même application, l'espace mémoire virtuel se subdivise en différents types de segments: texte, données, etc. A titre d'exemple non limitatif, lorsqu'une application donnée Appli s'exécute, ses différents composants sont partitionnés en segments d'espace virtuels: Texte T, Données Da (de différents types), piles St, mémoire partagée Shm, fichiers Fi, etc., comme illustré par la figure 4.30 Classiquement, un dispositif gestionnaire H, (ou "handler" selon la terminologie anglo- saxonne couramment utilisée), attribue à ces segments de mémoire virtuels des emplacements dans la mémoire physique globale Mem du système. On va maintenant décrire le mécanisme d'allocation de mémoire physique sur détection d'un défaut de page. On a indiqué précédemment qu'une application en cours d'exécution utilise les différents type de mémoire de façon également différente. De même, une application qui se déroule initialement dans un module donné (par exemple figure 2: Ma) peut se continuer dans un autre (par exemple figure 2: Mb), ou une instance supplémentaire de cette application peut se créer et s'exécuter dans un module différent. Si on suppose qu'un applicatif tente d'effectuer une instruction particulière, par exemple une instruction de chargement, ou "lload", à une adresse virtuelle déterminée, par exemple l'adresse arbitraire "10x 2000", l'unité centrale (par exemple figure 2: 10a) dans laquelle se déroule le processus en cours décode l'instruction et une table de correspondance d'adresses (non représentée) va être scrutée. Si l'entrée recherchée ne s'y trouve pas, il y a émission d'une exception qui se traduit par un défaut de page détecté par le gestionnaire H. Il est donc nécessaire, dans ces20 circonstances, d'attribuer un emplacement de mémoire physique pour l'adresse virtuelle "10x 2000" ci-dessus. Dans l'art connu, il n'existe qu'un seul type d'allocation. En d'autres termes, les règles utilisées sont uniques quel que soit le profil propre à l'application et le25 type de segment. Le gestionnaire H affecte donc un emplacement de mémoire physique conformément aux règles d'allocation utilisées par le système. Par exemple, conformément à ces règles, l'allocation s'effectue systématiquement dans la mémoire physique locale, c'est-à- 30 dire dans la mémoire 14a, si le processus se déroulait dans le module Ma sous la conduite d'une des unités centrales 10a à 13a. Cette règle peut s'avérer intéressante pour un segment de type texte, mais non optimisée pour d'autres types de segments. 11 2767938 Le mécanisme ci-dessus est illustré par la figure 5. L'applicatif Appli génère un défaut de page Fp et le gestionnaire H attribue un emplacement de la mémoire physique Mem (dont les partitions, Zl à Zn, ont été symbolisées par5 des traits en pointillé sur la figure 5), selon des règles prédéfinies. Comme il a été indiqué également, ces règles peuvent être modifiées, mais elles restent les mêmes pour toutes les applications et tous les types de segments. Tout au contraire, selon l'invention, l'allocation de la mémoire physique Mem va être réalisée conformément à un jeu de règles qui tiennent compte, d'une part, du profil propre à l'application, et d'autre part, dans un mode de réalisation préféré, du type de défaut de page. Les figures 6a et 6b illustrent le mécanisme d'allocation de la mémoire physique selon l'invention. Selon une caractéristique principale du procédé selon l'invention, on lie chaque application à un jeu de règles d'allocation prédéfinies. Pour ce faire, il est nécessaire20 d'associer chaque application Applix (x étant un indice arbitraire) à un profil particulier. Cette association s'effectue sous la conduite du système d'exploitation, ou "OS", qui le mémorise. La figure 6a illustre schématiquement le mécanisme de l'association. On a représenté, sur cette figure 6a, une application particulière Applix. Comme il a été indiqué, cette application Applix utilise divers types de mémoire: texte, données, etc. Sur la figure 6a, on a représenté six types de mémoire que l'on a référencé tyMl à tyM6. On lie chaque type de mémoire, tyMl à tyM6, à une règle30 d'allocation, parmi un jeu de règles prédéfinies que l'on précisera ci-après. Ces règles ont été référencées R1 à R6, étant entendu qu'il ne s'agit pas forcément d'un jeu de règles disjointes. En d'autres termes, à titre d'exemple, les règles R2 et R3 pourraient être identiques, même si les types 12 2767938 de mémoire tyM2 et tyM3 sont eux distincts. Le profil d'allocation de mémoire Pax qui vient d'être défini est lié par une association Ax à une application particulière Applix. Le profil Pax est donc une table à deux entrées: types de5 mémoire tyMi et règles Rj choisies parmi un jeu de règles prédéfinies, i et j étant des indices arbitraires. De façon générale, on peut définir une fonction association comme suit: Association_pa(Applix, Pax). Le profil d'allocation de mémoire lié à une application donnée peut être défini à l'initialisation de l'exécution de cette application ou, de façon dynamique, redéfini à tout moment pendant l'exécution, ce qui augmente la souplesse du procédé. Sur la figure 6b, les règles d'allocation prédéfinies ont été repérées sous la référence générale Rg. Lors de l'apparition d'une exception qui se traduit par un défaut de page, Fp, c'est-à-dire lorsque la table de correspondance d'adresses ne contient pas d'entrée pour une adresse20 virtuelle, le gestionnaire H recherche le profil Pax propre à l'application Applix tel qu'il vient d'être défini. Il détermine aussi, dans un mode de réalisation préféré, le type de défaut de page Fp. A partir de ces deux paramètres, il attribue des emplacements en mémoire physique, Zl à Zn, soit25 locaux (dans le même module), soit distants (dans un autre module), soit encore répartis sur l'ensemble de la mémoire Mem. Cette répartition, dépendant du profil Pax de l'application Applix et du type de défaut de page Fp, est symbolisée, sur la figure 6b, par des flèches multiples30 (contrairement à la flèche unique du procédé selon l'art connu représenté sur la figure 5). La fonction d'adressage Fad peut donc se formaliser de la façon suivante: Fad = F(Pax, Type Fp). 13 2767938 Le choix de la règle à appliquer pour l'allocation de mémoire est donc le résultat de la combinaison de deux paramètres. De façon plus précise, une application donnée Applix spécifie quelles règles d'allocation elle requière pour chaque type de segment de mémoire virtuel, parmi un jeu de règles prédéfinies. A titre d'exemple, les types de segments suivants sont couramment utilisés: segments "clients", segments de "mapping", segments "permanents", segments de10 "mémoire de travail" et segments de "bibliothèques partagées". Pour fixer les idées et sans que cela soit limitatif en quoi que ce soit de la portée de l'invention, on peut définir le jeu de règles suivant, que l'on repère par les15 codes précisés ci-dessous: - "P STRIPE": allocation en bandes parmi tout l'espace mémoire physique formant la ressource d'une application donnée, réparties dans la mémoire locale (même module) ou distante (modules différents); - "PLOCAL": la mémoire physique allouée est dans le même module que l'unité centrale ayant provoqué le défaut de page; - "P RANDOM": l'allocation de mémoire physique s'effectue au hasard parmi l'espace mémoire possible, à l'aide d'une fonction stochastique; - "P NONE" ou "PDEFAULT": il n'y a pas de règle d'allocation de mémoire physique spécifique, on utilise alors des règles par défaut propres au système. A titre d'exemple, l'allocation du type "P_STRIPE", définie ci-dessus, convient a priori pour des segments de type "mémoire partagée", alors que l'allocation de type "P LOCAL" convient a priori pour des segments du type "mémoire de travail". 14 2767938 Si l'on se reporte de nouveau à la figure 6a, et si l'on suppose que les types de mémoires utilisés par une application particulière Applix sont les suivants: "texte", "données", "heap", "mémoire partagée", "stack" et "bibliothèque partagée", le profil d'allocation de mémoire associé à l'application Applix sera décrit, par exemple, par la "TABLE I" placée en fin de la présente description. Le procédé selon l'invention permet ainsi d'optimiser au mieux les allocations de mémoires physiques aux besoins réels des applications, plus précisément des profils particuliers des applications. Les performances du système de traitement de l'information s'en trouvent améliorées, car les temps d'accès à la ressource mémoire sont optimisés, pour le moins si l'on raisonne en temps moyens d'accès. Un autre15 avantage est la possibilité de lier une application quelconque au jeu de règles d'allocation de mémoire prédéfinies sans qu'il soit nécessaire de la modifier ou de la recompiler, comme ce serait le cas si on utilisait une nouvelle "API", ainsi qu'il a été indiqué. En outre, le procédé présente une grande souplesse. Il permet notamment de fonctionner selon l'art connu. Par exemple, si des règles d'allocation ne sont pas spécifiées ou requises par une application donnée, les règles par défaut peuvent être utilisées ("PNONE" ou "P_DEFAULT"). D'autre25 part, une application "fille" peut "hériter" des règles d'allocation de mémoire associée à l'application "mère" qui l'a créée. Il peut en être de même d'une instance supplémentaire d'une application, qui se déroule par exemple dans un module différent. A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés. Elle permet notamment d'adapter au mieux l'utilisation de l'espace mémoire aux besoins réels des applications, c'est-à-dire en tenant compte de leurs profils 2767938 spécifiques et des différents types de mémoire qu'elles utilisent. Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits. Notamment, le procédé ne saurait se limiter au seul jeu de règles prédéfinies d'allocation de mémoire explicité dans la description. Il doit être clair aussi que, bien que particulièrement adaptée pour des architectures multiprocesseurs de type "NUMA" précité, on ne saurait cantonner l'invention à ce seul type d'applications. Le procédé de l'invention s'applique avantageusement à tout système de traitement de l'information dont les accès à la mémoire physique ne s'effectuent pas de façon uniforme, que15 cette mémoire soit distribuée ou non entre plusieurs machines ou modules. Enfin, bien que particulièrement adapté à un système d'exploitation du type "UNIX" ou similaire, il est clair que l'on ne peut cantonner le procédé de l'invention à ce seul20 environnement. 16 2767938 TABLE I Types de mémoire Règles texte "P STRIPE" données "P LOCAL" "heap" "P LOCAL" mémoire partagée "PSTRIPE" "stack" "P LOCAL" bibliothèque partagée "PRANDOM" 17 2767938 REVENDICATIONS 1. Procédé d'allocation d'emplacements de mémoire physique par mise en correspondance avec au moins une plage d'adresses contiguës de mémoire dans un espace d'adressage virtuel associée à une application logicielle déterminée (Applix), l'application (Applix) étant en cours d'exécution dans un système de traitement de l'information (1') comprenant une unité de mémoire à accès non uniforme (Mem) et utilisant plusieurs types de mémoire virtuelle (tyM1- tyM6), ladite mise en correspondance s'effectuant par scrutation d'une table de correspondance d'adresses, caractérisé en ce qu'il comprend une étape consistant à lier ladite application logicielle déterminée (Applix) à des règles d'allocation de mémoire (Rg) choisies parmi un jeu de règles prédéfinies, et en ce que, lorsque ladite table de correspondance d'adresses ne comporte pas d'entrée pour une plage d'adresses contiguës de mémoire d'adresse virtuelle associée à ladite application logicielle déterminée (Applix), il comprend une étape de génération d'une exception (Fp) et une étape subséquente d'allocation d'un emplacement (Zl-Zn) de mémoire physique selon une desdites règles d'allocation de mémoire (Rg), le choix de la règle étant assujetti à un profil desdits types de mémoire virtuelle utilisés (tyMl- tyM6) par l'application logicielle déterminée (Applix). 2. Procédé selon la revendication 1, caractérisé en ce que lesdites plages d'adresses contiguës de mémoire virtuelle se subdivisant en plusieurs catégories provoquant des types d'exception (Fp) distincts, il comprend une étape supplémentaire consistant à déterminer ledit type d'exception (Fp), et en ce que ladite règle d'allocation de mémoire est une fonction de la combinaison dudit profil et dudit type exception (Fp). 18 2767938 3. Procédé selon les revendications 1 ou 2, caractérisé en ce que ledit espace d'adressage virtuel est organisé en segments. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit système de traitement de l'information (1') étant constitué d'au moins deux modules distincts (Ma, Mb), comprenant chacun au moins un processeur (10a-13a, lOb-13b) et une unité de mémoire physique dite locale (14a, 14b), les unités de mémoire situées en dehors d'un module étant dites éloignées, ledit jeu de règles prédéfinies (Rg) comprend au moins les règles d'allocation de mémoire spécifiques suivantes, sur la génération d'une exception (Fp): - une première règle allouant un emplacement de mémoire exclusivement dans ladite unité de mémoire locale; - une deuxième règle allouant un emplacement de mémoire par distribution, selon des tranches, dans ladite unité de mémoire locale et lesdites unités éloignées; - et une troisième règle allouant un emplacement de mémoire, au hasard, dans ladite unité de mémoire locale et lesdites unités éloignées. 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend au moins une règle supplémentaire d'allocation de mémoire prédéterminée, dite par défaut, de manière à ce que, lorsque ladite application logicielle déterminée (Applix) ayant provoqué une exception (Fp) n'est liée à aucune desdites règles spécifiques, l'allocation de mémoire s'effectue selon ladite règle par défaut. 6. Procédé selon la revendication 4, caractérisé en ce que ladite application logicielle déterminée (Applix) 19 2767938 comportant au moins un segment de mémoire partagée avec d'autres applications, accédé de façon sensiblement égale par l'ensemble desdits modules (Ma, Mb), ladite étape subséquente d'allocation d'un emplacement de mémoire physique (Mem) s'effectue conformément à ladite deuxième règle, l'allocation étant effectuée par distribution sur lesdites unités de mémoire locale et éloignées (14a, 14b). 7. Procédé selon la revendication 4, caractérisé en ce que ladite application logicielle déterminée (Applix) comportant au moins un segment de mémoire de travail, accédé en local dans l'un desdits modules (Ma, Mb), ladite étape subséquente d'allocation d'un emplacement de mémoire physique (Mem) s'effectue conformément à ladite première règle, l'allocation étant effectuée exclusivement dans ladite unité de mémoire locale (14a ou 14b).