EP0935781A1 - Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur - Google Patents

Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur

Info

Publication number
EP0935781A1
EP0935781A1 EP98942788A EP98942788A EP0935781A1 EP 0935781 A1 EP0935781 A1 EP 0935781A1 EP 98942788 A EP98942788 A EP 98942788A EP 98942788 A EP98942788 A EP 98942788A EP 0935781 A1 EP0935781 A1 EP 0935781A1
Authority
EP
European Patent Office
Prior art keywords
memory
virtual
address
segment
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP98942788A
Other languages
German (de)
English (en)
Inventor
Thierry Bordaz
Patrice Romand
Jean-Dominique Sorace
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR9711025A external-priority patent/FR2767938B1/fr
Application filed by Bull SAS filed Critical Bull SAS
Publication of EP0935781A1 publication Critical patent/EP0935781A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1072—Decentralised address translation, e.g. in distributed shared memory systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms

Definitions

  • the present invention relates to a memory allocation method in a multiprocessor information processing system, more particularly to a memory allocation method with non-uniform access.
  • non-uniform is understood in a temporal sense, as will be shown.
  • memory has a general meaning. It can mean a distributed memory, a memory hierarchy (for example comprising memory banks with different access times), or a set of memories of different types.
  • SMP System etrical MultiProcessor
  • symmetrical multiprocessor allows different processors of the same machine to access its memory symmetrically by means of a system bus. These are machines with uniform access memory insofar as the memory access time is substantially the same for all the data accessed.
  • the information processing system 1 which will hereinafter be called the "SMP" module, comprises a certain number of central units or processors, or even “CPU” according to the English terminology.
  • central units have been shown in the example of FIG. 1: 10 to 13. These central units 10 to 13 are associated with a central memory 14 accessible to all.
  • a known solution consists in grouping several machines into clusters so as to make them communicate with each other by means of a network.
  • Each machine has an optimal number of processors, for example four, and its own operating system. It establishes a communication with another machine whenever it performs processing on data held up to date by this other machine.
  • the time required for these communications and the need to work on coherent data pose latency problems for large applications such as, for example, distributed applications which require numerous communications. Latency is the time between the instant of transmission of a memory access request and the instant at which the response to this request is received.
  • NUMA Non Uniform Memory Access
  • a "NUMA” type machine consists of several modules, each module comprising an optimal number of processors and a physical part of the total memory of the machine.
  • Such a machine has non-uniform memory access because a module generally has easier and faster access to a physical part of the memory which it does not share with another module than to a part which it shares.
  • each module has a private system bus connecting its processors and its physical memory
  • an operating system common to all the modules makes it possible to consider all of the private system buses as a single system bus of the machine.
  • Logical addressing assigns a place of residence to a determined physical memory location of a module.
  • a distinction is made between accesses to a part of local memory, physically located on the same module as the processor, and accesses to a part of remote memory, physically located on one or more modules other than that where the processor.
  • Figure 2 appended to this description schematically illustrates an example of architecture of this type, that is to say an architecture "NUMA".
  • the information processing system comprises only two modules, M a and Mb, of the aforementioned "SMP" type, and that the two modules are identical. It should however be clearly understood that the information processing system 1 ′ may comprise a greater number of modules and that the modules M a and Mb, may be different (in particular as regards the number of central units) .
  • the module M a therefore comprises four central units 10 a to 13 a / and a central memory 14 a .
  • the module Mb comprises four central units 10jb to 13b, and a central memory 14 £,.
  • the two memories 14 a and 14 & (and more generally the n main memories) communicate with each other using what is called a "link" 2, usually via so-called remote caches 15a and 15d, respectively.
  • the link 2 is not limited to simple physical links, but includes various conventional electronic circuits (control circuits, interface, etc.), which it is unnecessary to describe further.
  • the aforementioned dynamic correspondence or “mapping” is carried out according to rules common to all the applications whatever their types, without taking into account the location of the physical memory.
  • an exception is generated which is formalized by the detection of a fault in page, according to the terminology "UNIX" (registered trademark).
  • the term "page” can be defined more generally as a "range of contiguous addresses”. A page is a subdivision of a segment. However, for reasons of simplification, the term “page” will be used in the following.
  • a device called manager allocates physical memory, according to the aforementioned common rules.
  • the subject of the invention is therefore a method of allocating memory for an information processing system with non-uniform access to the central memory, in particular of the aforementioned "NUMA" type, which aims to meet the needs which arise. feel for this architecture particular and which does not have the drawbacks of the processes of the known art.
  • memory allocation is carried out according to the profile specific to each application, that is to say by implementing a set of allocation rules taking account of this profile between which, for each fault page detected, a search is automatically carried out which determines which should be executed for the allocation of physical memory.
  • the allocation of physical memory is also carried out, taking into account the type of page fault. Indeed, during its execution, an application is subdivided into different objects such as text, data, shared memory, etc., which use the global memory space of the system differently. The invention therefore also makes it possible to optimize the memory accesses as a function of this parameter.
  • the "virtual ranges" thus defined can have variable lengths.
  • a specific memory allocation policy is selectively associated with each of the virtual ranges or "ranges". This technical characteristic makes it possible to further optimize memory allocations in the event of page fault detection, at the cost of
  • the manager responsible for finding the rule to be executed examines a table in order to determine whether there is a specific allocation policy associated with this virtual range. If this specific policy does not exist, the policy governing the superior hierarchical unit that constitutes the segment is adopted. Otherwise, a memory allocation rule is derived from this specific policy.
  • the same segment can comprise one or more virtual ranges, or "ranges", each associated with a specific memory allocation policy, at the same time as one or more other virtual ranges obeying the general policy. of the segment, even of the system, and of the rules which result from it.
  • list structures are used to determine which memory allocation rule it is necessary to use, each element of the list corresponding to a range of contiguous addresses, delimited by the start and end addresses. from the virtual beach.
  • an item in the list is a memory location storing the memory allocation rules that apply to a given virtual range. The different elements of the list are scanned, sequentially, to determine which rules should be applied.
  • the segments are subdivided into N subspaces of contiguous virtual addresses, all of the same length.
  • a table called a "hash”, is also provided, also comprising N entries. These N entries are associated with as many individual list structures. The length of individual list structures is not fixed. It depends on the number of virtual ranges associated with this entry.
  • the address manager H knows the address which caused the page fault. It is therefore easy for him to determine the number of the corresponding entry in the table.
  • the "hash" table consists of N memory locations, each location storing at least one piece of information on the fact that there is a virtual range associated with this entry and which requires the use of a specific memory allocation policy.
  • a page fault when a page fault is detected, its entry in the table is read and as soon as there is a pointer characteristic of the presence of a specific allocation policy, it follows, without any additional step , determining that of the aforementioned virtual ranges of the segment which is associated with this page fault. For segments that do not include virtual ranges associated with a specific policy, the policy to be applied is that of the segment as a whole. On the other hand, for virtual ranges requiring specific memory allocation policies, it is necessary to scan one or more elements of a list structure associated with a particular entry in the table.
  • the subject of the invention is therefore a method of allocating physical memory locations by mapping to at least one range of contiguous memory addresses in a virtual address space associated with a specific software application, the application being executed in an information processing system comprising a memory unit with non-uniform access and using several types of virtual memory, said mapping being effected by scanning an address correspondence table , characterized in that it comprises at least one step consisting in linking said determined software application to memory allocation rules chosen from a set of predefined rules, and in that, when said address correspondence table does not include no entry for a range of contiguous addresses in the virtual address memory associated with said determined software application, it comprises takes a step of generating an exception and a subsequent step of allocating a physical memory location according to one of said memory allocation rules, the choice of the rule being subject to the profile of said types of virtual memory used by the software application determined.
  • FIG. 1 schematically illustrates an architecture of an information processing system with uniform memory access called "UMA”
  • FIG. 2 schematically illustrates an architecture of a system for processing information with non-uniform memory access called "NUMA”;
  • FIG. 4 illustrates an example of subdivision of a software application
  • FIG. 5 schematically illustrates the allocation of a memory location according to the known art, when generating a page fault
  • Figures 6a and 6b schematically illustrate the allocation of a memory location according to the invention, when generating a page fault
  • - Figures 7a and 7b illustrate an additional embodiment of the method according to the invention
  • FIG. 8 schematically illustrates a practical example of implementation of the variants of the method according to
  • FIG. 9 schematically illustrates a practical example of implementation of the additional embodiment of the method according to the invention, according to a first variant
  • - And Figures 10a to 10c schematically illustrate a practical example of implementation of the additional embodiment of the method according to the invention, according to a second variant.
  • the virtual address space can be divided into different types, including the following types:
  • an application or a new instance of the same application can be executed in one or the other of the two modules M a or Mb of the system of FIG. 2. This is true for the same application, the is even more for two applications with different profiles.
  • FIGS 3a and 3b schematically illustrate two types of applications, namely a "mini-database” (“minidatabase”) and a more traditional database.
  • the accesses are confined to an address space symbolically represented by the Zini zone, located arbitrarily on the left of FIG. 3a. Then, the accesses are made in an address space, symbolized by a zone Zf, also of restricted extent and supposed to be connected to the zone Zini, in the example of figure 3a.
  • the physical memory locations for this particular application, can therefore be confined in a single module, and more precisely locally.
  • the virtual memory space is subdivided into different types of segments: text, data, etc.
  • a manager device H or "handler” according to the English terminology commonly used, allocates to these virtual memory segments locations in the global physical memory Mem of the system.
  • the rules used are unique regardless of the profile of the application and the type of segment.
  • the manager H therefore assigns a physical memory location in accordance with the allocation rules used by the system. For example, in accordance with these rules, the allocation is systematically carried out in the local physical memory, that is to say in the memory 14 a if the process took place in the module M a under the supervision of one of the central units 10 a to 13 a .
  • This rule can be interesting for a text type segment, but not optimized for other types of segments.
  • the above mechanism is illustrated in FIG. 5.
  • the application Appli generates a page fault Fp and the manager H assigns a location of the physical memory Mem (whose partitions, Z to Z n , have been symbolized by lines dotted in Figure 5), according to predefined rules. As noted above, these rules can be changed, but they remain the same for all applications and all types of segments.
  • the allocation of the physical memory Mem will be carried out in accordance with a set of rules which takes into account, on the one hand, the profile of the application, and on the other hand , in a preferred embodiment, of the page fault type.
  • FIGS 6a and 6b illustrate the allocation mechanism of the physical memory according to the invention.
  • each application is linked to a set of predefined allocation rules. To do this, it is necessary to associate each application Appli ⁇ (x being an arbitrary index) with a particular profile. This association is carried out under the guidance of the operating system, or "OS", which stores it.
  • Figure 6a schematically illustrates the mechanism of the association.
  • FIG. 6a a particular application Appli ⁇ . As mentioned, this Appli ⁇ application uses various types of memory: text, data, etc.
  • FIG. 6a six types of memory have been represented, which have been referenced tyM to tyM ⁇ .
  • Each type of memory, tyM ⁇ to tyMç is linked to an allocation rule, among a set of predefined rules which will be specified below.
  • These rules have been referenced J? ⁇ to Re, it being understood that this is not necessarily a set of disjoint rules.
  • the rules R2 and R3 could be identical, even if the memory types tyM2 and tyM3 are themselves distinct.
  • the memory allocation profile Pa x which has just been defined is linked by an association Ax to a particular application Appli x .
  • the Pa x profile is therefore a table with two inputs: memory types tyM ⁇ and rules Rj chosen from a set of predefined rules, i and being arbitrary indices.
  • association function can be defined as follows:
  • the memory allocation profile linked to a given application can be defined at the initialization of the execution of this application or, dynamically, redefined at any time during the execution, which increases the flexibility of the process.
  • the manager H searches the Pa x profile of the Appli ⁇ - application as it has just been defined. It also determines, in a preferred embodiment, the type of page fault Fp. From these two parameters, it allocates locations in physical memory, Z to Z--. , either local (in the same module), or remote (in another module), or even distributed over the whole of the memory Mem. This distribution, depending on the profile Pa x of the application Appli ⁇ and the type of page fault Fp, is symbolized, in FIG. 6b, by multiple arrows (unlike the single arrow of the method according to the known art represented in the figure 5).
  • the addressing function F a can therefore be formalized as follows:
  • a given application Appli ⁇ specifies which allocation rules it requires for each type of virtual memory segment, from a set of predefined rules.
  • segments are commonly used: “client” segments, “mapping” segments, “permanent” segments, “working memory” segments and “shared library” segments.
  • P_STRIPE allocation in bands, among all the physical memory space forming the resource of a given application, distributed in the local memory (same module) or distant (different modules), according to a method called “round robin” ;
  • the allocation of the type P_STRIPE ", defined above, is suitable a priori for segments of the" shared memory "type, while the allocation of the type” P_LOCAL “is suitable a priori for segments of the type "working memory”.
  • the method according to the invention thus makes it possible to optimize the allocation of physical memories as much as possible according to the real needs of the applications, more precisely the particular profiles of the applications.
  • the performance of the information processing system is thereby improved, since the access times to the memory resource are also optimized, at least if we reason in terms of average access times.
  • Another advantage is the possibility of linking any application to the set of predefined memory allocation rules without having to modify or recompile it, as would be the case if we used a new "API", as well that it was indicated.
  • the process has great flexibility. It allows in particular to be able to operate according to known art. For example, if allocation rules are not specified or required by a given application, default rules from the system can be used ("P_DEFAULT"). On the other hand, a “daughter” application can "inherit” the memory allocation rules associated with the "mother” application that created it. It can be the same for an additional instance of an application, which takes place for example in a different module.
  • the method of the invention offers a significant improvement over the known art, and in particular better performance and great flexibility.
  • the virtual address space of current multiprocessor information processing systems can be extremely large.
  • a single segment represents for example 256 MB, or 2 pages.
  • These virtual subspaces even if they belong to a common segment, can be used in different ways by the various applications to which they are linked. It also follows that, for at least certain types of applications, the implementation of single rules for the whole of one or more segments that they use may not prove to be entirely optimized.
  • a given application Appli ⁇ is executed in one of the processors of the module M a , for example the processor 10 a .
  • This application notably manipulates a segment of the virtual address space of the system 1 ", arbitrarily referenced Sg x .
  • This segment Sgx is illustrated diagrammatically in FIG. 7b.
  • the virtual range Ra2 is assigned to the aforementioned application Appli et and, more precisely, it relates to an array whose capacity is 50 MB for example.
  • This table relates to a buffer memory, of the same capacity, located in one of the physical memories of the 1 "system.
  • the virtual ranges, or “ranges”, are selectively associated with specific rules.
  • each virtual range is associated with additional information defining a specific physical memory allocation policy.
  • this policy is optional.
  • the method in the variant which has just been described, makes it possible to optimize the allocation of physical memory as best as possible on detection of a page fault. As in the previous variants, it requires a modification of the operating system, but also slight modifications of the applications that use it.
  • policy [address, size (for example 50 MB), policy (for example P_FIXE), module (for example N ° 3)]
  • the method is particularly advantageous for applications which manipulate data on the same virtual space.
  • applications of the so-called "driver” type, and in particular disk and network “drivers”, that is to say peripheral or network management programs.
  • These applications call on “data” type segments in which there are buffers, memory ranges for which the application has the possibility of defining specific policies, through an instruction which can be will call "System policy”.
  • the profile Pa x generally comprises several types of memories. If we consider a given segment, its type is described by a record Sgcy in the table of segments Scb. This type refers to an element of the profile Pa x , which is in turn described, according to the invention, by additional data MPy, recorded in the table Scjb.
  • FIG. 8 therefore illustrates the main interactions between a given application Appli ⁇ and the table of segments Scb.
  • the additional data for each game includes several fields: the "prange” pointer field which specifies whether or not there is a specific policy to take into account in the segment, a field that the we will call “policy _type” which specifies the type of rule to apply ("P_FIXE", etc.) and a field which we will call “module” which specifies the module number, at least for certain types of rules (for example if the rule is "P_FIXE").
  • policy _type which specifies the type of rule to apply
  • module which specifies the module number, at least for certain types of rules (for example if the rule is "P_FIXE").
  • a list structure is adopted to organize the additional data sets, as illustrated diagrammatically in FIG. 9.
  • the addressed segment that caused the page fault includes z virtual ranges.
  • the first memory position of the list structure, in the table Scb includes data relating to the segment in its entirety, and in particular the global memory allocation policy for this segment. For an unmodified application, only this memory position exists.
  • the address in the segment that caused a page fault is known.
  • the H manager provides this address as well as the segment concerned, which will be called idx and pno, respectively. These data are used to address the Scb table.
  • the comparison of this pno address with the different bounds, low and high, of each list element, Ra_ to R z, (addresses "pno_start” and "pno_end"), makes it possible to determine whether it is necessary to apply a memory allocation policy specific to the virtual range concerned, and, if so, what type of policy should be applied (“policy _t pe”), and possibly which module number is concerned (“module”), depending on the type specified by the "policy _type” field.
  • This additional data is initialized when creating a segment, depending on the profile of the application concerned. They can then be modified by the application dynamically, through the aforementioned instruction of type "system policy”.
  • the global policy to be applied to the segment is of the "P_L0CAL" type, and therefore a module number is unnecessary, since the allocation is made in the module where the page fault occurred;
  • the manager H receives, in response to its request, data indicating a type "P_STRIPE" and a module number 3 , or M c in the example of FIG. 7a. This module number must be incremented (or more generally modified), since it is a rotating allocation by bands.
  • the determination of a specific allocation policy is carried out according to the diagram in FIGS. 10a to 10c.
  • the segments for example the Sgy segment, being there an arbitrary index, are subdivided into N sub-segments of fixed lengths.
  • a segment representing 256 MB of virtual memory it is advantageously subdivided into 256 sub-segments of 1 MB each, referenced SS to SSjj in FIG. 10b, which is advantageous since it s 'acts with a power of 2.
  • the hash table Th (FIG. 10a) also includes N entries corresponding to N memory sub-segments. Each of the entries stores the memory allocation policy specific to the sub-segments, SS ⁇ to SSIJ. Each of the memory locations of the table Th is associated with an individual list structure. More precisely, this list structure exists if, and only if, the sub-segment concerned comprises at least one zone belonging to a virtual memory range, or "range", to which a specific memory allocation policy must be applied. .
  • the entry e2 of the hash table Th is associated with a list structure comprising two elements, I ⁇ -ai2 and LRa22, storing the characteristics of the two specific policies, in the manner which was previously described.
  • the entries ei, ⁇ 3, es and ee and e ⁇ correspond to sub-segments of (same rank) which do not include virtual ranges associated with specific policies.
  • the entries ⁇ 4 and e ⁇ correspond to sub-segments comprising virtual ranges associated with specific memory allocation policies. It can be seen that the number of elements in each individual list, that is to say associated with an entry, is variable. Indeed, as has been indicated, virtual ranges, or "ranges", do not have a fixed length. In the example illustrated in FIG.
  • the list structure associated with the entry ⁇ 2 comprises two elements, LRa ⁇ 2 and LRa22
  • the list structure associated with the entry ⁇ 4 comprises an element, LRa ⁇ .
  • the list structure associated with the entry e ⁇ has three elements, LRa ⁇ to
  • the manager H When a page fault is detected, the manager H knows the virtual address which caused this page fault in a given segment, for example the segment of index idx and the pno address which makes it possible to find the rank of the sub -segment, for example the SS2 sub-segment •
  • the corresponding entry of the table Th is read. There is a high probability that the policy to be applied can be determined directly at this stage, by reading the information set recorded in the table Th. If this is not the case, only the elements of the list associated with a determined entry, corresponding to the sub-segment having caused the page fault are read, that is to say the elements associated with the entry N ° 2 in this case. These elements are, in each case limited in number, because they only cover a sub-segment, that is to say only 1 MB in the example described. As indicated, in the preferred application, under the "UNIX" environment, the minimum granularity of a virtual range, or "range”, is that of the page. The maximum number of ranges per sub-segment is therefore, at most, limited to the number of pages included in a sub-segment (256 in the example).
  • Virtual ranges are not fixed lengths. Certain ranges could then be "straddled" over two or more consecutive sub-segments. This is the case of a range extending over 50 MB for example, if a sub-segment has a length of 1 MB.
  • This problem can be solved by considering that the ranges can themselves be subdivided into sub-ranges, or "sub-ranges". This method is not penalizing because, at the time of their creation, the execution time is not critical, when detecting a page fault, it is however necessary that the allocation of a location of physical memory is very fast.
  • the entries p and p + 1 of the "hash" table Th are both initialized, through the above-mentioned instruction of the "system policy" type, when the virtual address range is created.
  • the entries p and p + 1 of the "hash” table Th are both initialized, through the above-mentioned instruction of the "system policy" type, when the virtual address range is created.
  • only one entry from the "hash” table Th is used. This is the one associated with this page fault, that is to say the one corresponding to a sub-segment (pno address).
  • the list items associated with these entries, LRa ⁇ p, etc., and LRa ⁇ (p + l), etc., respectively, are scanned to determine the memory allocation policy to be applied for l address that caused the aforementioned page fault.
  • multiple entries corresponding to several sub-segments and a single entry are used when a given virtual range is entirely included in a sub-segment, that is to say in a virtual subspace of 1 MO, in the example described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un procédé d'allocation d'emplacements de mémoire physique dans un système de traitement de l'information multiprocesseur comprenant une unité de mémoire (Mem) à accès non uniforme répartie entre plusieurs modules. Les applications logicielles (Appli?x?) sont liées à un jeu de règles d'allocation de mémoire prédéfinies (Rg). Lorsqu'il n'y a pas d'entrée pour une adresse virtuelle dans une table de correspondance d'adresses, il y a génération d'une faute de page (Fp). L'allocation d'un emplacement de mémoire physique (Mem) s'effectue selon une des règles prédéfinies en fonction du profil de l'application (Appli?x?) et du type de faute de page (Fp). Dans une variante de réalisation préférée, la mémoire est organisée en segments et les segments sont subdivisés en plages d'adressage virtuel. Ces plages peuvent être associées à une politique d'allocation de mémoire spécifique. Dans le cas contraire, c'est la politique du segment qui prévaut.

Description

PROCEDE D'ALLOCATION DE MEMOIRE DANS UN SYSTEME DE TRAITEMENT DE L'INFORMATION MULTIPROCESSEUR
Domaine technique ;
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. 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.
Technique antérieure :
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 "Sy etrical 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 "Unifor 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 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 à 1 ' 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é ou 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 pour 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 avec 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 volumineuses telles que, par exemple, les applications réparties qui 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 . Une 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 à une 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 bus 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ême 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 l' comprend seulement deux modules, Ma et Mb , du type "SMP" précité, et que les deux modules sont identiques. Il doit cependant être bien compris que le système de traitement de 1 ' information 1 ' peut comporter un 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 10jb à 13b , et une mémoire centrale 14£,. Les deux mémoires 14a et 14&, (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 des antémémoires dites éloignées 15a et 15j , 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" 14& 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 1 ' 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 entre 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 idées, dans ce qui suit, sans 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 pratique, un segment se définit comme un espace d'adresses virtuelles contiguës, de longueur fixe et déterminée.
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 que 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 ' ucune 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, selon la terminologie "UNIX" (marque déposée) . Le terme "page" peut être défini de façon plus générale comme étant une "plage d'adresses contiguës". Une page constitue une subdivision d'un segment. Cependant, pour des raisons de simplification, le terme "page" sera utilisé dans ce qui suit. Suite à une détection de défaut de page, un dispositif appelé gestionnaire attribue de la mémoire physique, et 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" du 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 se fait sentir de disposer d'un procédé d'allocation de mémoire qui minimise 1 ' 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, mais inappropriées, voire dangereuses pour une autre.
On a é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, en 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 pas s'appliquer telle quelle aux programmes existants.
En tout état de cause, elle manque de souplesse et son efficacité est limitée.
Exposé de 1 ' invention :
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ésente pas les inconvénients des procédés de l'art connu.
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 entre lesquelles, à chaque faute de page détectée, il est opéré automatiquement une recherche déterminant laquelle doit être exécutée pour l'allocation de mémoire physique.
Dans un mode de réalisation préféré, l'allocation de mémoire physique s'effectue en outre, en tenant compte du type de faute 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., qui utilisent différemment l'espace global de mémoire du système. L'invention permet donc d'optimiser également les accès mémoire en fonction de ce paramètre.
Le procédé de l'invention, dans les variantes qui viennent d'être mentionnées, offre une amélioration très significative par rapport à l'art connu, et notamment de meilleures performances et une grande souplesse. En outre, il n'est pas nécessaire de modifier les applications existantes. Cependant, il doit être noté que, dans la pratique, l'espace d'adressage virtuel d'un système de traitement de l'information multiprocesseur, notamment de type "NUMA", est habituellement très vaste. Pour fixer les idées, si le système d'exploitation est sous l'environnement "UNIX" précité ou une de ses variantes, un simple segment de mémoire virtuelle représente habituellement 256 MO. On conçoit aisément, dans ces conditions, qu'une règle unique par segment peut ne pas être optimisée pour un certain nombre d'applications, même si ce segment est associé à une seule classe : "type données", par exemple. Il est par ailleurs usuel de subdiviser un segment en sous-espaces d'adressage virtuel, que l'on appellera ci-après "plages virtuelles" ou encore "ranges" selon la terminologie anglo-saxonne. Les différentes zones d'adresses d'un segment, correspondant à ces plages virtuelles, peuvent être utilisées de façon différente.
Contrairement à une page, qui elle aussi forme une subdivision d'un segment, les "plages virtuelles" ainsi définies peuvent avoir des longueurs variables. De façon pratique, on admettra que, dans l'exemple d'application préférée (environnement "UNIX"), la granularité des plages virtuelles peut descendre jusqu'au niveau de la page.
Pour fixer les idées, on peut, par exemple, réserver une plage virtuelle de 50 MO pour un tableau définissant une mémoire physique tampon en vu de lire des données enregistrées sur un disque, par l'intermédiaire d'un contrôleur d'entrée-sortie.
Même si on se limite à cet exemple simple, on comprend que la localisation de la mémoire tampon dans l'une des mémoires physiques du système, dans le cas d'une architecture "NUMA", par rapport d'une part au module auquel est rattaché le disque précité, et d'autre part à l'application spécifique utilisant ces données, n'est pas indifférente, en terme de performances.
Aussi, selon une variante supplémentaire de l'invention, et toujours selon un mode de réalisation préféré, on associe sélectivement une politique d'allocation de mémoire spécifique à chacun des plages virtuelles ou "ranges". Cette caractéristique technique permet d'optimiser encore plus les allocations de mémoire en cas de détection de faute de page, au prix de
' modifications limitées apportées aux applications pour lesquelles cette variante du procédé de l'invention est mise en oeuvre. Selon cette variante, lorsqu'il y a génération d'une exception, qui se traduit par une faute de page, le gestionnaire chargé de trouver la règle à exécuter scrute une table en vue de déterminer s'il existe une politique d'allocation spécifique associée à cette plage virtuelle. Si cette politique spécifique n'existe pas, la politique gouvernant l'ensemble hiérarchique supérieur que constitue le segment est adoptée. Dans le cas contraire, une règle d'allocation de mémoire est dérivée de cette politique spécifique. En d'autres termes, un même segment peut comprendre une ou plusieurs plages virtuelles, ou "ranges", associées chacune à une politique d'allocation de mémoire spécifique, en même temps qu'une ou plusieurs autres plages virtuelles obéissant à la politique générale du segment, voire du système, et aux règles qui en découlent. Il doit être clair que le terme "spécifique" n'implique pas obligatoirement que la politique d'allocation associée à une plage donnée, repérée arbitrairement n (avec n compris entre 1 et m, si le segment comprend JT plages) , soit différente de celle associée à une ou plusieurs autres plages virtuelles, par exemple les plages virtuelles n+2 et n+5 .
De façon pratique, on recourt à des structures de liste pour déterminer quelle règle d'allocation de mémoire il est nécessaire d'utiliser, chaque élément de la liste correspondant à une plage d'adresses contiguës, délimitée par les adresses de début et de fin de la plage virtuelle. De façon pratique, un élément de la liste est un emplacement de mémoire stockant les règles d'allocation de mémoire qui s'appliquent à une plage virtuelle donnée. Les différents éléments de la liste sont scrutés, séquentiellement, pour déterminer quelles règles doivent être appliquées.
Ce processus peut encore être accéléré. Selon une variante supplémentaire de ce mode de mise en oeuvre de l'invention, on subdivise les segments en N sous-espaces d'adresses virtuelles contigus, tous de même longueur. On prévoit une table, dite de "hash", comprenant également N entrées . À ces N entrées sont associées autant de structures individuelles de listes. La longueur des structures de liste individuelles n'est pas fixe. Elle dépend du nombre de plages virtuelles associées à cette entrée. Lorsque une faute de page est détectée, le gestionnaire d ' adressage H connaît 1 ' adresse qui a provoquée la faute de page. Il lui est donc aisé de déterminer le numéro de 1 ' entrée correspondante dans la table.
La table "hash" est constituée de N emplacements de mémoire, chaque emplacement stockant au moins une information sur le fait qu'il existe une plage virtuelle associée à cette entrée et qui nécessite le recours à une politique spécifique d'allocation de mémoire. De façon pratique, lorsqu'une faute de page est détectée, son entrée dans la table est lue et dès lors qu'il existe un pointeur caractéristique de la présence d'une politique d'allocation spécifique, il s'ensuit, sans étape supplémentaire, la détermination de celle des plages virtuelles précitées du segment qui est associée à cette faute de page. Pour les segments ne comprenant pas de plages virtuelles associées à une politique spécifique, la politique à appliquer est celle du segment dans sa globalité. Par contre, pour les plages virtuelles nécessitant des politiques d'allocation de mémoire spécifiques, il est nécessaire de scruter un ou plusieurs éléments d'une structure de liste associés à une entrée particulière de la table. Cependant, la longueur de cette structure de liste est beaucoup plus limitée que dans le cas précédent, puisqu'elle ne couvre que les plages virtuelles associées à ladite entrée. Du fait de ces deux particularités, la variante de réalisation qui vient d'être décrite accélère bien le processus d'allocation de mémoire, pour le moins la phase de détermination des règles à appliquer.
L'invention a donc pour objet un 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, l'application étant en cours d'exécution dans un système de traitement de 1 ' information 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 au moins une étape consistant à lier ladite application logicielle 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'adresses virtuelles associées à ladite application logicielle 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 au profil desdits types de mémoire virtuelle utilisés par l'application logicielle déterminée.
Meilleure manière de réaliser l'invention ;
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 1 ' information à accès de mémoire uniforme dite "UMA" ; - la figure 2 illustre schématiquement une architecture de système de traitement de 1 ' 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'une faute de page ; 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'une faute de page ; - les figures 7a et 7b illustrent un mode de réalisation supplémentaire du procédé selon l'invention ; la figure 8 illustre schématiquement un exemple pratique d'implantation des variantes du procédé selon
1 ' invention dans un système de traitement de données numérique ; la figure 9 illustre schématiquement un exemple pratique d'implantation du mode de réalisation supplémentaire du procédé selon l'invention, selon une première variante ; - et les figures 10a à 10c illustrent schématiquement un exemple pratique d'implantation du mode de réalisation supplémentaire du procédé selon l'invention, selon une seconde variante.
Pour fixer les idées, sans limiter en quoi que ce soit la portée de l'invention, on se placera ci-après dans le contexte d'un système de traitement de l'information dont le système d'exploitation est du type "UNIX" ou similaire, sauf mention contraire. Pour les applications fonctionnant sous cet environnement, l'espace d'adressage virtuel peut être divisé en différents types, 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. En outre, une application ou une nouvelle instance de la même application peut s ' exécuter dans 1 ' un ou 1 ' autre des deux modules Ma ou Mb du système de la figure 2. Ce qui est vrai pour une même application, l'est encore plus pour deux applications de profils différents.
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 Λfejn.
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. 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 de la figure 3a. Les emplacements de mémoire physique, pour cette application particulière, peuvent donc être cantonnés dans un 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. Il 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 de mémoire virtuels : Texte , Données Da (de différents types) , Stack St , mémoire partagée Sh , fichiers Fi , etc., comme illustré par la figure 4. 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'une faute 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 différente également. 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) , u une instance supplémentaire de cette application peut se créer et s'exécuter dans un module différent.
Si on suppose qu'une application tente d'effectuer une instruction particulière, par exemple une instruction de chargement, ou "load", à une adresse virtuelle déterminée, par exemple l'adresse arbitraire "Oχ 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 une faute de page détectée par le gestionnaire H. Il est donc nécessaire, dans ces circonstances, d'attribuer un emplacement de mémoire physique pour l'adresse virtuelle "Oχ 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 de l'application et le 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-à-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.
Le mécanisme ci-dessus est illustré par la figure 5. L'application Appli génère une faute de page Fp et le gestionnaire H attribue un emplacement de la mémoire physique Mem (dont les partitions, Z à Zn , ont été symbolisées par 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 le procédé de l'invention, l'allocation de la mémoire physique Mem va être réalisée conformément à un jeu de règles qui tient compte, d'une part, du profil de l'application, et d'autre part, dans un mode de réalisation préféré, du type de faute 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écessaire d'associer chaque application Appliχ {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 Appliχ. Comme il a été indiqué, cette application Appliχ 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és tyM à tyMβ . On lie chaque type de mémoire, tyM± à tyMç, , à une règle 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 J?ι à Re , é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 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 de mémoire tyM± et règles Rj choisies parmi un jeu de règles prédéfinies, i et étant des indices arbitraires.
De façon générale, on peut définir une fonction association comme suit :
Association_pa (Appliχ, Pa%) .
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 une faute de page, Fp, c'est-à-dire lorsque la table de correspondance d'adresses ne contient pas d'entrée pour une adresse virtuelle, le gestionnaire H recherche le profil Pax de l'application Appliχ- tel qu'il vient d'être défini. Il détermine aussi, dans un mode de réalisation préféré, le type de faute de page Fp . A partir de ces deux paramètres, il attribue des emplacements en mémoire physique, Z à Z--. , soit 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 Appliχ et du type de faute de page Fp, est symbolisée, sur la figure 6b, par des flèches multiples (contrairement à la flèche unique du procédé selon l'art connu représenté sur la figure 5) .
La fonction d'adressage Fa peut donc se formaliser de la façon suivante :
Fad ≈ F (Pax, Type Fp) . 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 Appliχ spécifie quelles règles d'allocation elle requière pour chaque type de segment de mémoire virtuelle, 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 de "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 les 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) , selon une méthode de type dit "round robin" ;
- "P_LOCAL" : la mémoire physique allouée est dans le même module que 1 ' unité centrale ayant provoqué la faute de page ;
- "P_FIXE" : la mémoire physique allouée est dans un module prédéfini ;
- "P_DEFAULT" (ou "P_NONE" ) : il n'y a pas de règle d'allocation de mémoire physique, et l'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" . Le procédé selon l'invention permet ainsi d'optimiser au mieux les allocations de mémoires physiques en fonction des 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 aussi optimisés, pour le moins si l'on raisonne en temps moyens d'accès. Un autre 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. II permet notamment de pouvoir 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, des règles par défaut venant du système peuvent être utilisées ( "P_DEFAULT" ) . D'autre part, une application "fille" peut "hériter" des règles d'allocation de mémoire associées à 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.
Comme il est aisé de le constater, le procédé de l'invention, dans les variantes qui viennent d'être décrites, offre une amélioration significative par rapport à l'art connu, et notamment de meilleures performances et une grande souplesse.
Cependant, comme il a été indiqué dans le préambule de la présente description, l'espace d'adressage virtuel des systèmes de traitement de 1 ' information multiproceseurs actuels peut être extrêmement vaste. Dans le cadre de l'environnement "UNIX", un simple segment représente par exemple 256 MO, soit 2 pages. Aussi, il est d'usage de subdiviser les segments, en tant que de besoin, en "ranges" ou plages virtuelles, de longueurs variables. Ces sous- espaces virtuels, même s'ils appartiennent à un segment commun, peuvent être utilisés de manière différente par les diverses applications auxquelles ils sont liés. Il s'ensuit également que, pour certains types d'applications au moins, la mise en oeuvre de règles uniques pour la totalité d'un ou plusieurs segments qu'elles utilisent peut ne pas s'avérer entièrement optimisée.
A titre d'exemple non limitatif, on va considérer de nouveau un système de type "NUMA", par référence à la figure 7a. Ce système, référencé 1", est semblable au système 1 ' de la figure 2 , mais il est supposé comprendre au moins trois modules "SMP", Ma , Mb et M , interconnectés par un lien 2". On a également supposé que le module Mc était connecté à une unité de disques D , par l'intermédiaire d'un contrôleur et de circuits habituels d'entrée-sortie, sous la référence unique I/Oc
On suppose enfin qu'une application donnée Appliχ s'exécute dans un des processeurs du module Ma , par exemple le processeur 10a. Cette application manipule notamment un segment de l'espace d'adressage virtuel du système 1", référencé arbitrairement Sgx . Ce segment Sgx est illustré schématiquement par la figure 7b. Dans un but de simplification, on a supposé qu'il ne comporte que cinq plages virtuelles, ou "ranges", référencés Ra à Ras . Dans l'exemple décrit, la plage virtuelle Ra2 est attribuée à l'application Appliχ précitée et, de façon plus précise, elle concerne un tableau dont la capacité est de 50 MO par exemple. Ce tableau est relatif à une mémoire tampon, de même capacité, localisé dans une des mémoires physiques du système 1". Toujours dans l'exemple décrit, on a supposé que, du fait des règles associées au type de segment Sgx et au profil de l'application Appliχ, l'emplacement de mémoire tampon était physiquement localisé dans la mémoire centrale I4j du module Mb - Il s'ensuit que la lecture de données par l'application Appliχ nécessite, notamment, deux transits sur le lien 2", transits qui constituent des opérations particulièrement pénalisantes en termes de temps de traitement.
Pour éviter la nécessité d'un double transit, il eut été judicieux que les règles d'allocation retenues pour la plage virtuelle Ra2 imposent une localisation de la mémoire tampon de 50 Mo, soit dans la mémoire centrale physique du module Me (près des circuits I/Oc et de l'unité de disques D) , soit dans la mémoire centrale physique du module Ma , module où s'exécute l'application Applix. L'expérience montre, qu'en général, la première solution donne de meilleurs résultats, d'un point de vue performances .
Sur ce simple exemple, il est aisé de constater que, même si on met en oeuvre des règles d'allocation de mémoire adaptées au profil des applications, conformément au procédé de l'invention, voire modifiables dynamiquement, il subsiste des cas où le procédé n'est pas entièrement optimisé.
Aussi, selon un aspect supplémentaire du procédé selon l'invention, dans un mode de réalisation préféré, on associe sélectivement les plages virtuelles, ou "ranges", à des règles spécifiques.
Si on se reporte de nouveau au diagramme de la figure 7b, on a considéré que seules les plages virtuelles Ra2 et Ra/j. étaient associées à des règles spécifiques. Pour fixer les idées, la plage virtuelle i?a4 peut également représenter un tableau, mais cette fois-ci de 100 MO, par exemple. Les autres plages virtuelles
(représentées en traits hachurés sur la figure 7b) ne sont pas liées à des règles spécifiques. Dans ce cas, ce sont les règles associées à l'unité de mémoire virtuelle hiérarchiquement supérieure, en l'occurrence le segment Sgx, qui s'appliquent. Ceci s'effectue de la façon qui a été précédemment explicitée.
De façon plus précise, selon ce mode supplémentaire de réalisation, on associe à chaque plage virtuelle des informations supplémentaires définissant une politique spécifique d'allocation de mémoire physique. Toutefois, cette politique est optionnelle. En effet, les informations supplémentaires comprennent un premier champ, que l'on appellera le pointeur "prange" , indiquant si, pour un segment, on doit appliquer effectivement au moins une politique spécifique { "prange" ≠ O) pour une plage virtuelle ou "range", ou si c'est la politique d'allocation qui lui est associée globalement qui doit être appliquée ( "prange" = 0) .
Un deuxième champ concerne le type de politique. On retrouve, au niveau de la plage virtuelle, le jeu de règles précédemment énoncé pour un segment global : "P_STRIPE", "P_FIXE", etc.
Enfin, au moins pour certains types de politique d'allocation de mémoire, il est nécessaire de préciser le numéro ou 1 ' adresse du module dans lequel la mémoire physique sera allouée. Pour ce faire, il existe un troisième champ ou champ "N° de module". C'est le cas pour le type "P_FIXE" : il est nécessaire de préciser le numéro du module prédéfini. Pour le type "P_STRIPE" , il est en outre nécessaire de connaître le numéro du module précédemment utilisé pour 1 ' incrémenter selon la loi de distribution en bandes de mémoire utilisée ("round robin") . Il est donc nécessaire de mémoriser le numéro précédemment utilisé dans une position mémoire, un registre ou un compteur .
Si on se reporte de nouveau au diagramme de la figure 7b, les politiques d'allocation des plages virtuelles Ra± à Ras pourraient se décliner comme suit : - pour les plages virtuelles Ra± , Ra3 et Ras , pas de politique spécifique, les règles étant celles du segment Sgx, par exemple type = P_FIXE et numéro de module = N°de Ma ;
- pour la plage virtuelle Ra2 , existence d'une politique spécifique, avec type = P_FIXE et numéro de module = N° de M , comme il a été indiqué ci-dessus ;
- pour la plage virtuelle Ra/ , existence d'une politique spécifique, avec, par exemple, type ≈ P_FIXE aussi et numéro de module = N° de Mb -
Le procédé, dans la variante qui vient d'être décrite, permet d'optimiser au mieux l'allocation de mémoire physique sur détection d'une faute de page. Il nécessite, comme dans les variantes précédentes une modification du système d'exploitation, mais aussi des modifications légères des applications qui y font appel.
A titre d'exemple, si on considère des instructions de lecture et d'écriture, du type "bind" en terminologie "UNIX" , qui doivent s ' exécuter dans le module numéro 3 (soit, par exemple, le module Mc) , avec un tampon de 50 MO comme indiqué précédemment, il est nécessaire d'ajouter, dans le flot d'instructions, une instruction initialisant, sur appel système, une politique spécifique pour la plage virtuelle utilisée (par exemple Ra2 ) , instruction que l'on appellera "policy" . Celle-ci peut prendre la forme suivante :
policy [adresse , taille (par exemple 50 MO), politique (par exemple P_FIXE) , module (par exemple N° 3)]
Bien que toutes applications puissent tirer profit de cette variante de réalisation supplémentaire du procédé selon l'invention, il n'est cependant pas nécessaire de modifier tous les types d'applications. Il est utile de noter que celles qui ne sont pas modifiées peuvent s'exécuter normalement. La politique d'allocation de mémoire physique s'effectue de la manière décrite en regard des figures 6a et 6b. Les règles utilisées dépendent notamment du profil de ces applications et sont avantageusement celles définies précédemment, encore qu'elles puissent être différentes.
Par contre, le procédé, selon la variante supplémentaire, est particulièrement avantageux pour les applications qui manipulent des données sur un même espace virtuel. A titre d'exemples non exhaustifs, on peut citer les applications du type dit "driver", et notamment les "drivers" de disques et de réseau, c'est-à-dire des programmes de gestion de périphériques ou de réseau. Ces applications font appel à des segments de type "données" dans lesquelles il existe des tampons ou "buffers", plages de mémoire pour lesquelles l'application a la possibilité de définir des politiques spécifiques, au travers d'une instruction que 1 ' on appelera " System policy" .
D'autres types d'applications sont particulièrement concernés. Il s'agit des applications qui communiquent entre elles par l'intermédiaire de mémoires partagées. Par exemple, si on considère une première application qui s ' exécute dans un des processeurs du module Ma de la figure 7a et une deuxième application qui s'exécute dans un des processeurs de ce même module Ma , et partagent une première plage virtuelle d'un segment du type "mémoire partagée", il est intéressant, a priori pour des raisons de performances, que le type de politique d'allocation de mémoire soit "P_FIXE" ou "P_LOCAL" , et que le numéro de module soit égal à 1 (module Ma) . Cette disposition devrait, a priori , améliorer les performances du système. Il est donc utile d'affecter une politique spécifique d'allocation de mémoire à cette première plage virtuelle. De même, si une troisième application s'exécute dans le module Mb et partage, avec la première application, une seconde plage virtuelle, appartenant au même segment de type "mémoire partagée" , il peut être intéressant que le type de politique d'allocation de mémoire soit "P_FIXE" et que le numéro de module soit égal à 2 (module Mb) • Cette disposition devrait aussi, a priori , améliorer les performances du système. Il est donc également utile d'affecter une politique spécifique d'allocation de mémoire à cette seconde plage virtuelle.
On va maintenant décrire, dans un exemple de réalisation pratique, comment le procédé de l'invention, dans ces différentes variantes, peut être implanté sur une machine réelle. Pour fixer les idées, on se placera ci- après, sans que cela limite en quoi que ce soit la portée de l'invention, dans le cadre d'une machine sous environnement "UNIX" ou similaire.
Dans ce type de machine, il existe une table des segments Scb dans laquelle sont enregistrées des données définissant ces segments, notamment leurs types ou classes, comme illustré schématiquement sur la figure 8. Le procédé de l'invention tire parti de cette particularité.
Si on considère une application donnée Appliχ, on stocke son profil de mémoire Pax dans la structure ayant créé les segments utilisés par cette application. Le profil Pax, comme on l'a montré en relation avec la figure 6a, comprend généralement plusieurs types de mémoires. Si on considère un segment donné, son type est décrit par un enregistrement Sgcy dans la table des segments Scb . Ce type se réfère à un élément du profil Pax, qui est décrit à son tour, selon l'invention, par des données supplémentaires MPy, enregistrées dans la table Scjb.
Ces données supplémentaires MPy représentent précisément la politique d'allocation de mémoire à appliquer, soit au niveau global du segment Sgcy, soit au niveau des plages virtuelles, subdivisions de longueurs variables de ce segment. La figure 8 illustre donc les interactions principales entre une application donnée Appliχ et la table de segments Scb .
En réalité, et dans la mesure où une application a été modifiée pour supporter une politique d'allocation de mémoire spécifique au niveau des plages virtuelles, il existe plusieurs jeux de données supplémentaires pour chaque segment.
Comme il a été indiqué ci-dessus, les données supplémentaires de chaque jeu comprennent plusieurs champs : le champ du pointeur "prange" qui précise s'il existe ou non une politique spécifique à prendre en compte dans le segment, un champ que l'on appellera "policy _type" qui précise le type de règle à appliquer ("P_FIXE", etc.) et un champ que l'on appellera "module" qui précise le numéro de module, du moins pour certains types de règles (par exemple si la règle est "P_FIXE") . Pour délimiter les différentes plages virtuelles, il est en outre nécessaire de disposer d'informations précisant les adresses virtuelles des bornes basses et hautes de ces plages virtuelles. Ces informations figurent dans des champs que l'on appellera "pno_start" et "pno_end" , respectivement.
Lorsqu'une faute de page est détectée, il est donc nécessaire de balayer ces différentes données pour déterminer la politique d'allocation précise à appliquer. Selon un aspect de l'invention, on adopte une structure de liste pour organiser les jeux de données supplémentaires, comme illustré schématiquement par la figure 9.
On suppose que le segment adressé ayant causé la faute de page comprend z plages virtuelles. La première position mémoire de la structure de liste, dans la table Scb , comprend des données relatives au segment dans sa globalité, et notamment la politique globale d'allocation de mémoire pour ce segment. Pour une application non modifiée, seule cette position mémoire existe.
Les autres éléments de la liste, référencés Ra± à Raz , sont relatifs aux différentes plages virtuelles contiguës. On retrouve donc, pour chacun des éléments, les différents champs : "policy_type" , "module" , "pno_start" et "pno_end" pour les segments dont le pointeur "prange" est différent de zéro.
L'adresse dans le segment ayant causé une faute de page est connue. Le gestionnaire H fournit cette adresse ainsi que le segment concerné, que l'on appellera idx et pno , respectivement. Ces données permettent d'adresser la table Scb . La comparaison de cette adresse pno avec les différentes bornes, basses et hautes, de chaque élément de liste, Ra_ à R z , (adresses "pno_start" et "pno_end" ) , permet de déterminer s'il y a lieu d'appliquer une politique d'allocation de mémoire spécifique à la plage virtuelle concernée, et, si oui, quelle type de politique doit être appliquée ( " policy _t pe" ) , et éventuellement quel numéro de module est concerné ( "module" ) , selon le type précisé par le champ " policy _type" .
Ces données supplémentaires sont initialisées lors de la création d'un segment, en fonction du profil de l'application concernée. Elles peuvent ensuite être modifiées par l'application de façon dynamique, au travers de l'instruction précitée de type "systejîi policy" .
Pour fixer les idées et à titre d'exemple, on a fait les suppositions suivantes :
- la politique globale à appliquer au segment est du type "P_L0CAL", et donc un numéro de module est inutile, puisque l'allocation s'effectue dans le module où a eu lieu la faute de page ;
- la politique spécifique associée à la première plage virtuelle, c'est-à-dire celle enregistrée dans le premier élément de la liste LRa_ , comprend les champs suivants : "policy_type" = "P_FIXE" et "module" = 2 ;
- la politique spécifique associée à la deuxième plage virtuelle, c'est-à-dire celle enregistrée dans le deuxième élément de la liste LRa2 , comprend les champs suivants : "policy_type" ≈ "P_STRIPE" et "module" = 3 ;
la politique spécifique associée à la plage virtuelle z, c'est-à-dire celle enregistrée dans le dernier élément de la liste LRaz , comprend les champs suivants : "policyj ype" ≈ "P_DEFAULT" et "module" = " " (c'est-à-dire vide) .
Naturellement les champs d'adresses "pno_start" et " pno_end" sont également documentés pour chacune des plages virtuelles, 1 à z.
Si l'adresse pno pointe un espace déterminé par les champs d'adresse de l'élément de liste .LRa2, le gestionnaire H reçoit, en réponse à sa requête, des données indiquant un type "P_STRIPE" et un numéro de module 3 , soit Mc dans l'exemple de la figure 7a. Ce numéro de module doit être incrémenté (ou de façon plus générale modifié) , puisqu'il s'agit d'une allocation tournante par bandes.
Le procédé conforme à la variante qui vient d'être décrite peut encore être amélioré. Il est en effet possible d'augmenter les performances du système, en diminuant le temps nécessaire pour déterminer la politique d'allocation de mémoire à appliquer pour une plage virtuelle, sur détection d'une faute de page. Pour ce faire, dans une variante du mode de réalisation supplémentaire qui vient d'être décrit, on utilise une table de plages virtuelles, à adressage calculé, c'est-à-dire à code dit de "hash" selon la terminologie anglo-saxonne.
La détermination d'une politique spécifique d'allocation s'effectue selon le diagramme des figures 10a à 10c. Les segments, par exemple le segment Sgy, y étant un indice arbitraire, sont subdivisés en N sous-segments de longueurs fixes. Dans l'environnement "UNIX" précité, un segment représentant 256 MO de mémoire virtuelle, on le subdivise avantageusement en 256 sous-segments de 1 Mo chacun, référencés SS à SSjj sur la figure 10b, ce qui est avantageux, puisqu'il s'agit d'une puissance de 2.
La table de "hash" Th (figure 10a) comprend également N entrées correspondant à N sous-segments de mémoire. Chacune des entrées stocke la politique d'allocation de mémoire spécifique aux sous-segments, SS± à SSIJ . À chacun des emplacements mémoires de la table Th est associée une structure de liste individuelle. Plus exactement, cette structure de liste existe si, et seulement si, le sous-segment concerné comprend au moins une zone appartenant à une plage de mémoire virtuelle, ou "range", à laquelle une politique d'allocation de mémoire spécifique doit être appliquée.
Si on se reporte à la figure 10b, on a supposé que
"prange" pour le segment Sgy était différent de zéro, donc que ce segment comprenait au moins une plage virtuelle associée à une politique d'allocation mémoire spécifique.
On a supposé que le sous-segment SS± ne comportait aucune plage virtuelle associée à une politique spécifique.
C'est également le cas, sur la figure 10b, des sous- segments SS3 et SSN . Par contre, on a supposé que le sous- segment SS2 comprenait trois plages, ou "ranges", Jao2 à Ra22 - L première, RaQ2 , n'est pas associée à une politique spécifique, les deux autres, Ra±2 à R 22 , sont associées à des politiques d'allocations de mémoire spécifiques, par exemple "P_FIXE" et "P_STRIPE", respectivement.
Il s'ensuit que l'entrée e2 de la table de "hash" Th est associée à une structure de liste comprenant deux éléments, I<-ai2 et LRa22 , emmagasinant les caractéristiques des deux politiques spécifiques, de la manière qui a été précédemment décrite.
Sur la figure 10a, il a été supposé que les entrées ei, β3, es et ee et e^, correspondent à des sous-segments de (même rang) qui ne comprennent pas de plages virtuelles associées à des politiques spécifiques. Par contre, outre l'entrée e2 déjà citées, les entrées β4 et eη correspondent à des sous-segments comprenant des plages virtuelles associées à des politiques d'allocation de mémoire spécifiques. On constate que le nombre d'éléments de chaque liste individuelle, c'est-à-dire associée à une entrée, est variable. En effet, comme il a été indiqué, les plages virtuelles, ou "ranges", n'ont pas une longueur fixe. Dans l'exemple illustré sur la figure 10a, la structure de liste associée à l'entrée β2 comporte deux éléments, LRaχ2 et LRa22 , la structure de liste associée à l'entrée β4 comporte un élément, LRa ^. , et la structure de liste associée à l'entrée eη comporte trois éléments, LRa η à
Lorsqu'une faute de page est détectée, le gestionnaire H connaît l'adresse virtuelle qui a provoqué cette faute de page dans un segment donné, par exemple le segment d ' indice idx et 1 ' adresse pno qui permet de trouver le rang du sous-segment, par exemple le sous-segment SS2 •
Lors d'une première étape, l'entrée correspondante de la table Th est lue. Il existe une forte probabilité que la politique à appliquer puisse être déterminée directement à cette étape, par la lecture du jeu d'informations enregistrés dans la table Th . Si tel n'est pas le cas, seuls les éléments de la liste associés à une entrée déterminée, correspondant au sous-segment ayant causé la faute de page sont lus, c'est-à-dire les éléments associés à l'entrée N° 2 en l'occurrence. Ces éléments sont, à chaque fois en nombre restreint, car ils ne couvrent qu'un sous-segment, c'est-à-dire seulement 1 MO dans l'exemple décrit. Comme il a été indiqué, dans l'application préférée, sous environnement "UNIX", la granularité minimale d'une plage virtuelle, ou "range", est celle de la page. Le nombre maximum de plages par sous-segment est donc, au plus, limité au nombre de pages comprises dans un sous-segment (256 dans l'exemple).
Le processus d'acquisition des données nécessaire à la détermination d'une politique d'allocation de mémoire à appliquer est donc accéléré du fait des deux caractéristiques qui viennent d'être rappelés.
Les plages virtuelles, comme il a été rappelé, ne sont pas de longueurs fixes. Certaines plages pourraient alors se trouver "à cheval" sur deux sous-segments consécutifs, voire plus. C'est le cas d'une plage s 'étendant sur 50 MO par exemple, si un sous-segment a une longueur de 1 MO. Ce problème peut être résolu en considérant que les plages peuvent elles-mêmes être subdivisées en sous-plages, ou "sub-ranges" . Cette méthode n'est pas pénalisante car, au moment de leur création, le temps d'exécution n'est pas critique, lors de la détection d'une faute de page, il est par contre nécessaire que l'attribution d'un emplacement de mémoire physique soit très rapide.
Dans le cadre de la variante du mode de réalisation supplémentaire qui vient d'être décrite, et si on se réfère maintenant à la figure 10c, on suppose, à titre d'exemple, qu'une faute de page a eu lieu pour une adresse virtuelle comprise dans un sous-segment donné. On suppose que la plage virtuelle lors de sa création a été subdivisée et répartie sur deux sous-segments consécutifs, de rangs arbitraires p et p+1.
Dans ce cas, les entrées p et p+1 de la table de "hash" Th sont toutes deux initialisées, au travers de l'instruction précitée de type "system policy" , lors de la création de la plage d'adresses virtuelles. Lors d'une faute de page, une seule entrée de la table de "hash" Th est utilisée. Il s'agit de celle associée à cette faute de page, c'est-à-dire encore celle correspondant à un sous- segment (adresse pno) .
S'ils existent, les éléments de liste associés à ces entrées, LRa±p, etc., et LRa± (p+l) , etc., respectivement, sont scrutés pour déterminer la politique d'allocation de mémoire à appliquer pour l'adresse ayant causé la faute de page précitée.
De façon plus générale, on utilise des entrées multiples correspondant à plusieurs sous-segments et une entrée unique lorsqu'une plage virtuelle donnée est entièrement comprise dans un sous-segment, c'est-à-dire dans un sous-espace virtuel de 1 MO, dans l'exemple décrit.
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 spécifiques et des différents types de mémoire qu'elles utilisent. En outre, dans le mode de réalisation supplémentaire, un degré d'optimisation plus important peut être obtenu en descendant à un niveau plus fin, c'est-à- dire au niveau de ce qui a été appelé "plage virtuelle" ou "range", au prix de modifications légères des applications utilisant cette possibilité. Toutefois, même si ce mode de réalisation préféré est effectivement implanté dans la machine, il n'est pas nécessaire de modifier tous les types d'applications. Les applications non modifiées peuvent s'exécuter tel quel et bénéficient de l'amélioration des performances autorisées par les . premiers modes de réalisation du procédé, et la politique d'allocation de mémoire est la politique applicable au niveau des segments. On peut généralement se contenter de ne modifier que les applications pour lesquelles le gain de performances escompté est important : applications manipulant des données sur un espace virtuel qu'il est important de localiser, comme les "drivers" de disques et de réseau, etc.
II 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.
II 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, que cette mémoire soit distribuée ou non entre plusieurs machines ou modules.
Enfin, bien que particulièrement adapté à un système d'exploitation sous environnement "UNIX" ou similaire, il est clair que l'on ne peut cantonner le procédé de l'invention à ce seul environnement.

Claims

R E V E N D I C A T I O N S
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 (Appliχ) , 1 ' application (Appliχ) é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 (tyM_-tyMs ) , 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 (Appliχ) à 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 (Z_-Zn) de mémoire physique selon une desdites règles d'allocation de mémoire (Rg) , le choix de la règle étant assujetti au profil (pax) desdits types de mémoire virtuelle utilisés ( tyM -tyMe ) par 1 ' 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) .
3. Procédé selon les revendications 1 ou 2 , caractérisé en ce que ledit espace d'adressage virtuel est organisé en segments (Sgx, Sgy) et en ce que lesdits segments (Sgx, Sgy) sont associés auxdites règles (Rg) d'allocation de mémoire.
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', 1") étant constitué d'au moins deux modules distincts (Ma-Mc) , comprenant chacun au moins un processeur (10a-13a/ 10j-13j) et une unité de mémoire physique dite locale (14a 1 j ) , 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 fixe préétabli, dans ladite unité de mémoire locale ou lesdites unités éloignées, par référence à un numéro affecté auxdits modules.
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 (Appliχ) 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 (Appliχ) comportant au moins un segment de mémoire partagé 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 (Appliχ) comportant au moins un segment de mémoire de travail, accédé en local dans l'un desdits modules (Ma- M ) / 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) .
8. Procédé selon l'une quelconque des revendications 4 à 7 , caractérisé en ce que lesdits segments étant subdivisés en plages d'adressage virtuelles (Ra -Ras ) , chacune étant allouée à au moins l'une desdites applications (Appliχ) , en ce qu'il est prévu une première donnée numérique spécifiant s'il existe au moins une plage d'adressage virtuel (Ra_-Ras) à laquelle est associée à une règle d'allocation de mémoire spécifique, et en ce que ladite politique comprend au moins une deuxième donnée numérique spécifiant la nature de ladite règle d'allocation de mémoire et une troisième donnée numérique consistant en un numéro optionnel adressant l'un desdits modules (Ma-Mc) •
9. Procédé selon la revendication 8 , caractérisé en ce qu'il comprend, lors de ladite génération d'une exception (Fp) concernant une adresse comprise à l'intérieur de ladite plage d'adressage virtuelle (Ra±- Ras ) , une étape de lecture de ladite première donnée numérique, et une étape subséquente consistant à allouer un emplacement de mémoire physique conformément aux règles d'allocation de mémoire régissant le segment (Sgx, Sgy) lorsque ladite exception se traduit par un adressage de la mémoire ne correspondant à aucune desdites plages d'adressage virtuelle (Rai-Ras) -
10. Procédé selon la revendication 8, caractérisé en ce que ladite deuxième donnée numérique spécifie au moins l'une des règles suivantes :
- 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 ;
- une troisième règle allouant un emplacement de mémoire fixe préétabli, dans ladite unité de mémoire locale ou lesdites unités éloignées ;
- et une quatrième règle, dite par défaut, allouant un emplacement de mémoire selon une politique d'allocation de mémoire globale audit système de traitement de l'information, ladite quatrième règle étant du type de l'une desdites première à troisième règles.
11. Procédé selon la revendication 10, caractérisé en ce que, lorsque ladite deuxième donnée numérique spécifie lesdites deuxième ou troisième règles d'allocation de mémoire, ladite troisième donnée consiste en un numéro de module (Ma-Mc) à partir duquel est déterminé le module (Ma-Mc) dans lequel doit être effectué ladite allocation de mémoire.
12. Procédé selon les revendications 10 ou 11, caractérisé en ce que, ledit système de traitement de 1 ' information comprenant une table de description des segments (Scb) comportant des entrées en nombre égal auxdits segments (Sgχr Sgy) dudit espace virtuel, il comprend une étape initiale d'enregistrement desdites politiques d'allocation de mémoire dans ladite table de description de segments (Scb) et une étape initiale d'enregistrement desdits profils (Pax) dans des espaces de mémoire virtuelle occupés par lesdites applications (Appliχ) qui leur sont associées.
13. Procédé selon la revendication 12, caractérisé en ce que chacun desdits enregistrements de politique d'allocation de mémoire (Mpy) comprend au moins un premier champ stockant ladite première donnée numérique, un deuxième champ stockant ladite deuxième donnée numérique et un troisième champ stockant ladite troisième donnée numérique.
14. Procédé selon la revendication 13, caractérisé en ce que lesdits enregistrements comprennent deux champs supplémentaires, un premier champ stockant une donnée numérique spécifiant la borne d'adresse inférieure dans un segment déterminé (Sgx, Sgy) de ladite plage d'adressage virtuel et un second champ stockant une donnée numérique spécifiant la borne d'adresse supérieure de cette plage d'adressage virtuel, et en ce qu'il comprend les phases suivantes :
- une phase préliminaire consistant à créer, à la demande desdites applications., pour chaque segment comprenant au moins une plage virtuelle associée à une politique spécifique d'allocation de mémoire, une structure de liste comprenant des éléments en cascade (LRa -LRaz) en nombre égal auxdites plages d ' adressage virtuel (Ra_- Ras ) comprises dans ledit segment (Sgx, Sgy) , chaque élément stockant lesdits enregistrements de politique d'allocation de mémoire ainsi que lesdits premier et second champ supplémentaire d'adresse, et étant associé à l'une des plages d'adressage virtuel (Ra -Ras ) ;
- une phase subséquente, lors de la génération d'une exception (FP) à une adresse comprise dans un segment déterminé (Sgx, Sgy) comprenant au moins les étapes suivantes :
a/ des étapes successives consistant en la lecture des données numériques stockées dans lesdits éléments de la structure de liste en cascade (LRa -LRaz) ;
b/ pour chacune des éléments de liste, une étape consistant en la comparaison de ladite adresse ayant provoqué 1 ' exception (FP) avec lesdites bornes d'adresses inférieure et supérieure ;
c/ en cas de comparaison positive, une étape de lecture desdites deuxième et troisième données numériques, de manière à générer une instruction d'allocation de mémoire physique, conforme à ladite règle, et effectuée dans le module (Ma-Mc) dont le numéro est spécifié optionnellement en fonction de cette règle, ou en 1 ' absence de règle spécifiée par ladite deuxième donnée numérique, à allouer un emplacement de mémoire physique conformément aux règles d'allocation de mémoire régissant le segment (Sgx, Sgy) incluant la plage d'adressage virtuelle (Rai-Ras) .
15. Procédé selon la revendication 13, caractérisé en ce que lesdits enregistrements comprennent deux champs supplémentaires, un premier champ stockant une donnée numérique spécifiant la borne d'adresse inférieure dans un segment déterminé de ladite plage d ' adressage virtuel (Rai-Ras) et un second champ stockant une donnée numérique spécifiant la borne d'adresse supérieure de cette plage d'adressage virtuel (Rai-Ras ) , et en ce qu'il comprend les phases suivantes :
- une première phase préliminaire supplémentaire comprenant les étapes suivantes :
1/ une première étape consistant à subdiviser chacun desdits segments (Sgy) comprenant au moins une plage virtuelle associée à une politique spécifique d'allocation de mémoire en sous-segments (SSI-SSN) de mêmes longueurs fixes ; et
2/ une deuxième étape consistant à créer une table (Th) comprenant autant d'entrées (ei-e^) que de sous- segments (SSi-SSu) ;
une deuxième phase préliminaire supplémentaire consistant à créer, pour chaque sous-segment (SSi-SSu) , associé à chacune desdites entrées, une structure de liste (LRai2~LRa22 , Raiή. , LRaiη-LRazη ) comprenant des éléments en cascade en nombre égal auxdites plages d'adressage virtuel (Rao2~Ra22 ) comprises dans le sous- segment (SSI-SSN) , chaque élément stockant lesdits enregistrements de politiques d'allocation de mémoire ainsi que lesdits premier et second champ supplémentaires d'adresse, et étant associé à l'une des plages d'adressage virtuel (RaQ2~R 22 ) 1
- une phase subséquente, lors de la génération d'une exception à une adresse comprise dans un sous-segment (SSi-SSu) déterminé comprenant au moins les étapes suivantes :
- a/ la lecture de ladite entrée de la table (Th) associée à l'adresse ayant causé ladite exception et la détermination à partir de cette lecture si ledit sous- segment (SSi-SSu) inclue ou non une plage d'adressage virtuel (Rai-Ras ) régie par une politique d'allocation de mémoire spécifique, et en cas de détermination négative, l'utilisation de la règle régissant ledit segment (Sgy) ;
b/ en cas de détermination positive, des étapes successives consistant la lecture des données numériques stockées dans lesdits éléments de la structure de liste en cascade (L_Rai2-I/aRa22 LRai4 , LRaιη-LRa2η ) associée à l'entrée liée à l'adresse ayant causé ladite exception ;
- c/ pour chacune des éléments de liste (LRai2~LRa22 ,
LRai4 , LRa η-LRa.2η ) , une étape consistant en la comparaison de ladite adresse ayant provoqué l'exception avec lesdites bornes d'adresses inférieure et supérieure ;
- d/ en cas de comparaison positive, une étape de lecture desdites deuxième et troisième données numériques, de manière à générer une instruction d'allocation de mémoire physique conforme à ladite règle et effectuée dans le numéro de module (Ma-Mc) , spécifié optionnellement en fonction de cette règle.
16. Procédé selon la revendication 15, caractérisé en ce que lesdites plages d'adressage de mémoire virtuelle (R o2~ a22 ) étant de longueurs variables, lorsque ladite longueur est supérieure à la longueur desdits sous-segments (SSI-SSN) de longueur fixe, lesdites plages d'adressage de mémoire virtuelle sont subdivisées en sous-espaces compris dans des sous- segments (SSi-SSβf) .
17. Procédé selon les revendications 15 ou 16, caractérisé en ce que lesdits segments (Sgy) s'étendent sur un espace virtuel contigu de 256 MO et en ce que ladite table (Th) comporte 256 entrées (eι-e#) , chacune correspondant à un sous-segment (SSI-SSN) de 1 MO.
EP98942788A 1997-09-04 1998-08-26 Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur Withdrawn EP0935781A1 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
FR9711025A FR2767938B1 (fr) 1997-09-04 1997-09-04 Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur
FR9711025 1997-09-04
FR9808058A FR2767939B1 (fr) 1997-09-04 1998-06-25 Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur
FR9808058 1998-06-25
PCT/FR1998/001855 WO1999012099A1 (fr) 1997-09-04 1998-08-26 Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur

Publications (1)

Publication Number Publication Date
EP0935781A1 true EP0935781A1 (fr) 1999-08-18

Family

ID=26233786

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98942788A Withdrawn EP0935781A1 (fr) 1997-09-04 1998-08-26 Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur

Country Status (8)

Country Link
US (1) US6272612B1 (fr)
EP (1) EP0935781A1 (fr)
JP (1) JP2000506659A (fr)
CN (1) CN1237252A (fr)
AU (1) AU9079398A (fr)
BR (1) BR9806150A (fr)
FR (1) FR2767939B1 (fr)
WO (1) WO1999012099A1 (fr)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2774788B1 (fr) 1998-02-12 2000-03-24 Bull Sa Procede de controle d'acces memoire sur une machine avec memoire a acces non uniforme et machine pour mettre en oeuvre ce procede
US20020032844A1 (en) * 2000-07-26 2002-03-14 West Karlon K. Distributed shared memory management
US6742105B1 (en) * 2000-12-22 2004-05-25 Silicon Access Networks Method and system for range matching
US6871219B2 (en) 2001-03-07 2005-03-22 Sun Microsystems, Inc. Dynamic memory placement policies for NUMA architecture
DE10113577A1 (de) 2001-03-20 2003-01-09 Sap Ag Verfahren, Computerprogrammprodukt und Computersystem zur Unterstützung mehrerer Anwendungssysteme mittels eines einzelnen Datenbank-Systems
US7117488B1 (en) * 2001-10-31 2006-10-03 The Regents Of The University Of California Safe computer code formats and methods for generating safe computer code
US20030110205A1 (en) * 2001-12-07 2003-06-12 Leith Johnson Virtualized resources in a partitionable server
IL147073A0 (en) * 2001-12-10 2002-08-14 Monosphere Ltd Method for managing the storage resources attached to a data network
AU2002343180A1 (en) * 2001-12-14 2003-06-30 Koninklijke Philips Electronics N.V. Data processing system having multiple processors
US7433948B2 (en) * 2002-01-23 2008-10-07 Cisco Technology, Inc. Methods and apparatus for implementing virtualization of storage within a storage area network
US6823498B2 (en) * 2002-01-09 2004-11-23 International Business Machines Corporation Masterless building block binding to partitions
US7579771B2 (en) * 2002-04-23 2009-08-25 Semiconductor Energy Laboratory Co., Ltd. Light emitting device and method of manufacturing the same
US7786496B2 (en) 2002-04-24 2010-08-31 Semiconductor Energy Laboratory Co., Ltd. Semiconductor device and method of manufacturing same
JP2003317971A (ja) 2002-04-26 2003-11-07 Semiconductor Energy Lab Co Ltd 発光装置およびその作製方法
US7897979B2 (en) * 2002-06-07 2011-03-01 Semiconductor Energy Laboratory Co., Ltd. Light emitting device and manufacturing method thereof
AU2003240116A1 (en) * 2002-06-20 2004-01-06 British Telecommunications Public Limited Company Distributed computer
JP4216008B2 (ja) * 2002-06-27 2009-01-28 株式会社半導体エネルギー研究所 発光装置およびその作製方法、ならびに前記発光装置を有するビデオカメラ、デジタルカメラ、ゴーグル型ディスプレイ、カーナビゲーション、パーソナルコンピュータ、ｄｖｄプレーヤー、電子遊技機器、または携帯情報端末
US6986016B2 (en) * 2002-09-30 2006-01-10 International Business Machines Corporation Contiguous physical memory allocation
CN101982950B (zh) * 2002-10-04 2013-03-27 思达伦特网络有限责任公司 管理用于ip联网的资源
JP4373086B2 (ja) 2002-12-27 2009-11-25 株式会社半導体エネルギー研究所 発光装置
GB0230331D0 (en) * 2002-12-31 2003-02-05 British Telecomm Method and apparatus for operating a computer network
JP2006525607A (ja) * 2003-04-30 2006-11-09 シリコン・グラフィックス・インコーポレイテッド コンピュータシステムにおいてアドレス変換を実行するシステム及び方法
US7114040B2 (en) * 2004-03-02 2006-09-26 Hewlett-Packard Development Company, L.P. Default locality selection for memory objects based on determining the type of a particular memory object
US7426622B2 (en) * 2004-03-10 2008-09-16 Hewlett-Packard Development Company, L.P. Rapid locality selection for efficient memory allocation
US7574419B2 (en) * 2004-05-13 2009-08-11 Oracle International Corporation Automatic tuning of undo retention
US8756200B2 (en) * 2004-05-14 2014-06-17 Oracle International Corporation Undo advisor
JP2005332145A (ja) * 2004-05-19 2005-12-02 Nec Electronics Corp データ転送制御回路及びデータ転送方法
GB0412655D0 (en) * 2004-06-07 2004-07-07 British Telecomm Distributed storage network
US20060031672A1 (en) * 2004-08-03 2006-02-09 Soltis Donald C Jr Resource protection in a computer system with direct hardware resource access
US7930539B2 (en) * 2004-08-03 2011-04-19 Hewlett-Packard Development Company, L.P. Computer system resource access control
CN101963829A (zh) * 2004-12-31 2011-02-02 钟巨航 支持多个子系统的数据处理系统主板
US7447869B2 (en) * 2005-04-07 2008-11-04 Ati Technologies, Inc. Method and apparatus for fragment processing in a virtual memory system
US7996585B2 (en) * 2005-09-09 2011-08-09 International Business Machines Corporation Method and system for state tracking and recovery in multiprocessing computing systems
US7885939B2 (en) * 2005-10-11 2011-02-08 Oracle International Corporation Longest query duration for auto tuning undo retention
US7801932B2 (en) * 2005-10-11 2010-09-21 Oracle International Corporation Undo hints to speed up segment extension and tuning of undo retention
TWI348652B (en) * 2005-10-17 2011-09-11 Via Tech Inc Driver assisted asynchronous command processing
US7693884B2 (en) * 2006-01-02 2010-04-06 International Business Machines Corporation Managing storage systems based on policy-specific proability
US7599973B2 (en) * 2006-01-12 2009-10-06 Sun Microsystems, Inc. Method and apparatus for decreasing object copying by a generational, copying garbage collector
WO2007092615A2 (fr) 2006-02-09 2007-08-16 Monosphere Inc. Planification de la capacite de stockage
US7562186B2 (en) * 2006-04-11 2009-07-14 Data Domain, Inc. Efficient data storage using resemblance of data segments
US7949824B2 (en) * 2006-04-11 2011-05-24 Emc Corporation Efficient data storage using two level delta resemblance
US7844652B2 (en) * 2006-04-11 2010-11-30 Emc Corporation Efficient computation of sketches
US20080005528A1 (en) * 2006-06-30 2008-01-03 Morris Robert P Methods, Systems, and Computer Program Products for Using a Structured Data Storage System to Provide Access to Addressable Entities in Virtual Address Space
US20080005728A1 (en) * 2006-06-30 2008-01-03 Robert Paul Morris Methods, systems, and computer program products for enabling cross language access to an addressable entity in an execution environment
US20080127220A1 (en) * 2006-06-30 2008-05-29 Robert Paul Morris Methods, systems, and computer program products for creating an input-value-specific loadable instance of an application
US20080005752A1 (en) * 2006-06-30 2008-01-03 Robert Paul Morris Methods, systems, and computer program products for generating application processes by linking applications
US20080005719A1 (en) * 2006-06-30 2008-01-03 Morris Robert P Methods, systems, and computer program products for providing a program execution environment
US20080005529A1 (en) * 2006-06-30 2008-01-03 Morris Robert P Methods, Systems, and Computer Program Products for Providing Access to Addressable Entities Using a Non-Sequential Virtual Address Space
US20080005727A1 (en) * 2006-06-30 2008-01-03 Robert Paul Morris Methods, systems, and computer program products for enabling cross language access to an addressable entity
US7734890B2 (en) * 2006-10-06 2010-06-08 Okralabs Llc Method and system for using a distributable virtual address space
US20080221974A1 (en) * 2007-02-22 2008-09-11 Alexander Gilgur Lazy Evaluation of Bulk Forecasts
US8768895B2 (en) * 2007-04-11 2014-07-01 Emc Corporation Subsegmenting for efficient storage, resemblance determination, and transmission
US20080320282A1 (en) * 2007-06-22 2008-12-25 Morris Robert P Method And Systems For Providing Transaction Support For Executable Program Components
US20080320459A1 (en) * 2007-06-22 2008-12-25 Morris Robert P Method And Systems For Providing Concurrency Control For Addressable Entities
US9102962B2 (en) * 2007-10-16 2015-08-11 Shiu Nan Chen Production method for solid cultured active mushroom mycelium and fruit-body metabolites (AMFM) products thereof
JP5401903B2 (ja) * 2008-10-03 2014-01-29 富士通株式会社 故障情報監視装置及び故障情報監視方法
CN101729272B (zh) * 2008-10-27 2013-01-23 华为技术有限公司 内容分发方法、系统、设备及媒体服务器
CN102474531B (zh) * 2009-09-17 2015-08-12 国际商业机器公司 地址服务器
US9817700B2 (en) * 2011-04-26 2017-11-14 International Business Machines Corporation Dynamic data partitioning for optimal resource utilization in a parallel data processing system
GB2500707B (en) 2012-03-30 2014-09-17 Cognovo Ltd Multiprocessor system, apparatus and methods
US9495718B2 (en) * 2012-06-08 2016-11-15 Advanced Micro Devices, Inc. System and method for providing low latency to applications using heterogeneous processors
US9483263B2 (en) * 2013-03-26 2016-11-01 Via Technologies, Inc. Uncore microcode ROM
WO2017016616A1 (fr) * 2015-07-30 2017-02-02 Hewlett-Packard Development Company, L.P. Procédé et système de contrôle d'accès mémoire
CN106250241A (zh) * 2016-08-02 2016-12-21 合肥奇也信息科技有限公司 一种多方向分配数据处理系统资源到应用程序的方法
US11422750B2 (en) 2017-09-27 2022-08-23 Intel Corporation Computer program product, system, and method to manage access to storage resources from multiple applications
US10983832B2 (en) 2019-02-14 2021-04-20 International Business Machines Corporation Managing heterogeneous memory resource within a computing system
US11567803B2 (en) * 2019-11-04 2023-01-31 Rambus Inc. Inter-server memory pooling

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6105053A (en) * 1995-06-23 2000-08-15 Emc Corporation Operating system for a non-uniform memory access multiprocessor system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9912099A1 *

Also Published As

Publication number Publication date
US6272612B1 (en) 2001-08-07
BR9806150A (pt) 1999-10-26
JP2000506659A (ja) 2000-05-30
WO1999012099A1 (fr) 1999-03-11
FR2767939B1 (fr) 2001-11-02
CN1237252A (zh) 1999-12-01
FR2767939A1 (fr) 1999-03-05
AU9079398A (en) 1999-03-22

Similar Documents

Publication Publication Date Title
WO1999012099A1 (fr) Procede d&#39;allocation de memoire dans un systeme de traitement de l&#39;information multiprocesseur
EP1043658B1 (fr) Procédé d&#39;amélioration des performances d&#39;un système multiprocesseur comprenant une file d&#39;attente de travaux et architecture de système pour la mise en oeuvre du procédé
EP1909169B1 (fr) Système et procédé de stockage de masse
EP3586221B1 (fr) Procédé, équipement et système de gestion du système de fichiers
US8606791B2 (en) Concurrently accessed hash table
US6804761B1 (en) Memory allocation system and method
EP0466265A1 (fr) Dispositif de contrôle pour une mémoire tampon à partitionnement reconfigurable
FR2937755A1 (fr) Dispositif pour gerer des tampons de donnees dans un espace memoire reparti sur une pluralite d&#39;elements de memoire
US5765192A (en) Method and computer program product to reuse directory search handles
US20130091326A1 (en) System for providing user data storage environment using network-based file system in n-screen environment
EP0604310B1 (fr) Procédé de gestion d&#39;une mémoire tampon, et système informatique l&#39;incorporant
US11409670B2 (en) Managing lock coordinator rebalance in distributed file systems
EP2726985B1 (fr) Dispositif et procede de synchronisation de taches executees en parallele sur une plateforme comprenant plusieurs unites de calcul
EP0251861B1 (fr) Unité de gestion de mémoire
EP3506110B1 (fr) Accès multiples à un fichier de données stocké dans un système de stockage de données associé à un espace mémoire tampon
EP2802992A1 (fr) Systeme et procede de gestion de correspondance entre une memoire cache et une memoire principale
WO2012097944A1 (fr) Systeme multi-cœurs et procede de coherence de donnees
FR3074939A1 (fr) Procede de gestion du systeme de fichiers d&#39;un terminal informatique
FR2986346A1 (fr) Procede d&#39;utilisation d&#39;une memoire partagee
EP3239851B1 (fr) Gestion de l&#39;accès a des données dans un système de stockage
FR2767938A1 (fr) Procede d&#39;allocation de memoire dans un systeme de traitement de l&#39;information multiprocesseur
FR2787901A1 (fr) Organisation memoire par zones physiques
US20240106626A1 (en) Execution of homomorphically encrypted code using dynamically selected blocks
EP2652624B1 (fr) Procede, programme d&#39;ordinateur et dispositif de gestion d&#39;acces memoire dans une architecture multiprocesseurs de type numa
US11507611B2 (en) Personalizing unstructured data according to user permissions

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT CH DE FR GB IE IT LI

17P Request for examination filed

Effective date: 19990913

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Withdrawal date: 20020420