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/48—Program initiating; Program switching, e.g. by interrupt
  • G06F9/4806—Task transfer initiation or dispatching
  • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Definitions

• the invention relates to the management of interruptions on a computer platform.
• the platform also called machine or node
• the platform comprises at least one unit (also called module).
• a NUMA (Non Uniform Memory Access in English) type platform is particularly well suited to the invention and will therefore serve as an example in the description.
• This platform comprises a plurality of units. On this type of platform, the units are interconnected.
• a unit includes at least one processor.
• This platform includes an operating system common to all the units and includes a kernel that the skilled person most often calls "kernel”.
• the core performs a number of basic functions.
• the two main functions of the kernel are memory management and task management.
• the operating system offers the possibility of creating extension modules external to the kernel such as extension kernels. There is then in the system a basic kernel and extension kernels associated with device drivers. A “modern version” UNIX (registered trademark) type operating system is perfectly suited in this case.
• the subject of the invention is a method for managing interruptions on a computer platform, as well as a computer platform for implementing the method.
• task management by the operating system kernel includes taking into account and processing interruptions.
• the management of interruptions depends on the number and type of devices present on the platform. Traps are associated with device drivers. Interrupt management is included in the operating system kernel.
• the kernel is a source program written in an advanced language and is therefore subject, before its actual use, to compilation.
• a compiler program is software that translates the entire program and then runs it.
• the big problem is the intimate link between interrupt management and the operating system kernel. Compiling the kernel freezes a configuration state of the platform. As a result, a compilation freezes a maximum number of interrupts that can be supported by the operating system.
• configuration designates the composition of a unit, that is to say the memory capacity, the types of floppy drives, the capacity of the hard disk, the type of printer, etc.
• configuration also includes the number of units present on the platform.
• Compiling the kernel therefore has the serious drawback of limiting the total number of interruptions.
• This limitation is an obstacle to the exploitation of certain “large” configurations which evolve very quickly. Indeed, the frozen state of the system and the number of interruptions prevents a system from evolving. Adding or removing units on the platform becomes problematic.
• a recompilation is also costly in time in the sense that it involves completely revalidating the operating system / platform pair. Indeed, the operating system kernel, following the recompilation, may not function or not systematically correspond to a platform. A new version of an operating system on a platform must undergo series of tests on all platforms subject to a change in its operating system
• a solution provided by the prior art, to remedy the problem of compilation and the drawbacks which it entails, consists in that the kernels are generally sold compiled with a maximum of peripheral resource drivers in order to be compatible with a majority of types of peripheral resources We foresee, in a way, all the possible configurations on a platform This forecasting aspect has the serious consequence of an unnecessary expenditure of memory space for “small” configurations For example, a management system interruptions can provide for a number of interruptions of the order of a hundred thousand, while a small configuration system requires only ten interruptions
• a NUMA type platform is generally made up of several units connected to each other through a bus The different units therefore communicate with each other via a single, so-called system bus.
• a unit includes at least one processor surrounded by hardware elements such as memories, device drivers, etc.
• a first object of the invention is to have management of interruptions adaptable to platforms whose configuration is constantly evolving, and thus not to impose recompilation of the basic kernel of the operating system following a modification of the platform configuration.
• a second goal is to create an interface compatible with existing platforms.
• Existing platforms will thus be able to preserve their basic core and a fortiori their own system for managing interruptions.
• a third object of the invention is to have management of interruptions providing the processors with a performance gain.
• a fourth goal is to significantly reduce the cost of money and time involved in changing the configuration of a platform.
• the subject of the invention is a method for managing interruptions on a computer platform composed of at least one unit including at least one processor and at least one interrupt controller, of an operating system.
• a basic kernel making it possible to create extension modules external to said basic kernel, characterized in that it consists in creating at least one extension management module for interrupts external to the basic kernel so as to unload the basic kernel of interrupt management.
• the result is a computer platform comprising at least one unit including at least one processor and at least one interrupt controller, said platform including an operating system making it possible to create extension modules and lines of interruption connecting resources to controllers of interruption, characterized in that it comprises a software module for extending the management of interruptions for the implementation of the method.
• FIG. 1 is a partial schematic view illustrating the architecture of a known platform on which the method according to the invention can be applied.
• FIG. 2 is a partial schematic view used to illustrate the process according to the invention, the view including extension modules for managing the interruptions used by the process.
• Figure 3 is a schematic view of the parameters included in each extension module shown in Figure 2.
• FIG. 1 represents an example of a platform PF on which the invention can be applied.
• the platform PF has two units M1 and M2.
• the number of units is not limited to two but can be any number.
• a unit usually has both physical and logical resources. For reasons of simplification, the term resources will be used to designate these two types of resources.
• a unit, for example M1 comprises at least one processor PRO1 and PRO2, at least one memory MEM1, and at least one interrupt controller CM.
• the unit M1 comprises a single interrupt controller CI1.
• the M1 unit includes resources associated with device drivers noted IO1 in the drawing, such as as expansion cards or auxiliary circuits.
• the unit M2 comprises at least one processor PRO3, PRO4 and PRO5, at least one memory MEM2 and at least one interrupt controller.
• the unit M2 comprises a single interrupt controller CI2.
• the unit M2 includes resources associated with device drivers denoted IO2.
• a bus B1 connects the various peripheral resources to the interrupt controller CM.
• Another bus connects the interrupt controller CM to the processors PRO1 and PRO2 and to the memory MEM1.
• a bus B2 connects the various peripheral resources of the unit M2 to the interrupt controller CI2.
• Another bus connects the interrupt controller CI2 to the processors PRO3, PRO4 and PRO5 and to the memory MEM2.
• Interruption lines LU and LI2 connect the respective interruption controller CM and CI2 to the various resources.
• the units are linked together via a BS bus called the system bus. Data transfer between the different units is carried out via this BS bus.
• the CM and CI2 controllers only process one interrupt at a time.
• the controllers CM and CI2 order and deliver, in a manner known to those skilled in the art, the interrupts to a processor according to the level of the interrupt to be processed.
• the level of an interrupt depends on the priority that is assigned to a resource during initialization. It therefore manages the priorities of the various interrupts (also called interrupt level) emanating from the device drivers.
• An operating system SE is common to the whole platform. This operating system includes a basic NOY kernel responsible for handling interrupts on the PF platform. In addition, the SE operating system allows you to load expansion modules external to the kernel such as expansion kernels.
• the operating system SE is, for example, a UNIX type operating system "modern version”.
• the interrupts are of both hardware and software type, known to those skilled in the art. Software interrupts are triggered by programs when they need to execute, for example a memory management function.
• the called function is considered by the processor as a subroutine which, once completed, returns control to the caller Hardware and software interruptions are put on the same level, only the type of call distinguishes them
• a software interruption it is the program which fixes the interruption number while in a hardware interruption, it is the device itself which takes care of it
• the basic core NOY illustrated is common to all the units of the platform PF, in this case M1 and M2
• the unit M1 comprises two processors and is linked to the core of NOY base
• the M2 unit includes three processors and is linked to the same NOY base core
• the problem is the very intimate link between the management of interrupts and the operating system kernel This link implies a complete recompilation of the basic NOY kernel with each update of the platform
• An update can be the adding a unit or deleting a unit on the platform
• An update also includes a modification of the configuration of a unit, for example M1
• the method of the invention consists in creating at least one extension module for managing the interrupts MEX1 and MEX2 external to the basic kernel so as to unload the basic kernel NOY from managing the interrupts.
• the method consists for example in associating, with each extension module for managing interruptions MEX1 and MEX 2, at least one respective unit M1 and M2
• a “small” configuration means, for example, a configuration with a small number of units
• the “large” configurations can include a large number of units
• the platform can be of the “large” configuration type.
• the processors lose their performance. It is therefore desirable to associate with a expansion module as few units as possible
• each unit is associated with an extension module and therefore provides local interrupt management for each unit
• the units M1 and M2 are associated to the respective extension modules MEX1 and MEX2
• the platform can be of the “small” configuration type where the performance of the processors is not a determining factor.
• the process can preferably consist in the creation of a single extension module. of the management of interrupts external to the basic kernel of the operating system In this example, all the units are managed through this single module
• the method of the invention therefore consists, on each update, of recompiling only the extension module.
• the compilation simply concerns the extension module associated with a unit on which a modification of the configuration has been brought
• the compilation only concerns the one and only plug-in
• Each extension module preferably has an administrative structure and allows either the use of a software or hardware management model
• Both the software model and the hardware model involve two hierarchical software mechanisms, a primary mechanism and a secondary mechanism.
• the main mechanism is responsible for memorizing an interrupt request and determines the priority associated with this interrupt, which the skilled person most often names the interrupt level
• the main mechanism establishes an array containing the types of interruption and the associated priority
• the main mechanism manages the interrupt controller, for example CM
• the secondary mechanism is triggered directly following the second level mechanism
• FIG. 3 is a schematic view parameters characterizing the new services offered by the platform and contained in the interruption management extension module
• a processor for example PRO1
• PRO1 is associated with an indexed pointer table, commonly called interruption vector, that the processor will consult in response to an interrupt
• This table includes the address of the interrupt procedure associated with the interrupt request
• the basic NOY kernel must export a function responsible for executing the registration of the new services offered by the extension module for managing interruptions, for example MEX1 In the example illustrated, it consists of inserting these new services into the table
• This function can have six parameters, such as s as illustrated, which serve as an interface between the basic kernel and the interrupt management extension module. The number of parameters can be extended beyond six parameters to cover possible functionalities. All six parameters are associated with a device driver which itself is associated with an interrupt level
• the first parameter P1 describes the address of a function which allows device drivers to register the addresses of their own interrupt management routines. To this end, two sub-parameters are used. A first sub-parameter allows identification of the interruption that the mechanism 10
• a second sub-parameter allows the identification of the device driver itself so that it can be called.
• This function makes use of the internal administration structure of the extension module for managing interruptions, for example MEX1.
• This administration structure can be in the form of a table or a chain or a combination of the two and makes it possible to store the interruptions not yet processed.
• the interrupt controller for example CM, emits an interrupt in the direction of the processor PRO1.
• the processor PRO1 is interrupted at a determined interrupt level. At this level of interruption, it has a function queue which is stored in memory at determined addresses which it must call. These addresses correspond to interrupt routines associated with device drivers.
• the processor calls all of these functions in cascade.
• the second parameter P2 describes the address of a function which makes it possible to cancel the previous recording. If you decide to use a new device driver, this function eliminates the address of the corresponding interrupt routine from the previous table. The contents of the address table can therefore vary. The table is not frozen in time.
• the third parameter P3 is similar to the first parameter P1 and describes the address of a function that allows device drivers to register the addresses of the exception routines in the event of a power failure. Indeed, such a failure prevents the complete completion of a task such as writing or reading on a disk of the platform.
• the parameter P2 therefore corresponds in memory to the address of a routine to warn the device that the last transfer made is not valid. Under no circumstances should the device take this transfer into account and prevent the disk system from being inconsistent.
• the fourth parameter P4 describes the address of a function which makes it possible to simulate by software the arrival of an external interrupt.
• This simulation function presents the interrupt management extension module with a 11
• This function performs processing identical to that which would have been carried out if the interrupt level had been that of a hardware interrupt sent by a coupler.
• the electronic hardware card that links a peripheral resource to a processor is called a coupler.
• This function can be used to test software. Thanks to this function, we avoid waiting for a real interruption to appear before testing the software specific to the invention. Preferably, this function is used to test the program already compiled in order to detect logic errors.
• the fifth parameter P5 describes the address of the main interrupt management mechanism.
• the main mechanism is called by the nucleus when the interruption occurs.
• the parameter used identifies the processor.
• the parameter also identifies the associated unit in the event that the platform has more than one unit.
• the function associated with this parameter only calls the device drivers whose addresses appear in the internal administration structure.
• the function records the fact that there has been an interruption in the internal administration structure.
• this function signals to the basic kernel, via the exported function, that an interrupt is awaiting processing. The indication of the priority of the interrupt is provided in this function at this time. In both cases, this function is also responsible for acknowledging the interrupt at the interrupt logic level.
• a sixth parameter P6 describes the address of the secondary interrupt management mechanism. This function is not called in the case of a hardware management model, the secondary mechanism being triggered directly following the processing of the interrupt by the main mechanism. This function is called in the case of a software management model. It calls this function if the priority indicated is more favorable than that being processed. 12
• the subject of the invention is a method for managing interruptions on a computer platform PF composed of at least one unit M1 and M2 each including at least one respective processor PRO1-PRO2 and PRO3-PRO5 and at least one respective interrupt controller CM and CI2, of an operating system SE including a basic core NOY and making it possible to create extension modules external to said basic core, characterized in that it consists in creating at least one extension module for handling the interrupts MEX1 and MEX2 external to the basic kernel NOY so as to offload the basic kernel from interrupt management.
• the update may consist in modifying the configuration of an M1 and / or M2 unit or else in adding or modifying the number of units on the PF platform.
• a certain number of parameters define the new services offered by the platform PF after an update.
• the method then consists, on initialization, for the basic NOY kernel, of exporting a function in the MEX1 and MEX2 extension module to record in its tables the addresses of the management functions it will have to use.
• the method can consist in associating at least one respective unit M1 and M2 with each extension module for managing interruptions MEX1 and MEX2.
• the method can consist of the creation of a single extension module for managing the interruptions common to the whole PF platform.
• the method of the invention also preferably consists, for the extension module, of using either a software or hardware interrupt management model. 13
• the result is a computer platform PF comprising at least one unit M1 and M2 including at least one respective processor PRO1-PRO2 and PRO3-PRO5 and at least one respective interrupt controller CM and CI2, said platform PF including a system of SE to create extension modules and interrupt lines L1 connecting resources to interrupt controllers CM and CI2, characterized in that it includes at least one software module for extending interrupt management for the implementation of the process.
• the interrupt lines L1 connect a controller CM and CI2 of a respective unit M1 and M2 to all the resources of this same unit.
• This interface is provided by at least one extension module for interrupt management.
• This new interface does not require compilation of the basic operating system kernel in response to a change in the architecture of the platform.
• Another advantage of the invention is the creation of an interface compatible with existing systems. Existing platforms will be able to preserve their basic core and a fortiori their system for managing interruptions. Also, more particularly on “large” configurations, the invention provides processors with a performance gain compared to current interrupt management systems because the management of interruptions is carried out on each unit.
• the system may comprise only a single module for extending the interrupts. This variant may well be suitable for "small” platforms whose aim is not to improve the performance of the processors.
• a last advantage of the invention is the considerable reduction in the cost of money caused by adding or removing a unit on a platform. Indeed, a modification of the configuration no longer requires to recompile the basic kernel of the operating system but simply a compilation of the extension module for handling interruptions.

Applications Claiming Priority (3)

Publications (1)

Family

ID=9522640

Family Applications (1)

Country Status (4)

Families Citing this family (3)

Family Cites Families (8)

• 1998
  • 1998-02-05 FR FR9801363A patent/FR2774489B1/fr not_active Expired - Fee Related
• 1999
  • 1999-02-01 EP EP99901674A patent/EP0976040A1/de not_active Withdrawn
  • 1999-02-01 WO PCT/FR1999/000199 patent/WO1999040513A1/fr active Application Filing
  • 1999-02-01 US US09/402,394 patent/US6539436B2/en not_active Expired - Lifetime

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events