WO1992003783A1 - Procede de mise en ×uvre des fonctions du noyau - Google Patents

Procede de mise en ×uvre des fonctions du noyau Download PDF

Info

Publication number
WO1992003783A1
WO1992003783A1 PCT/US1991/004067 US9104067W WO9203783A1 WO 1992003783 A1 WO1992003783 A1 WO 1992003783A1 US 9104067 W US9104067 W US 9104067W WO 9203783 A1 WO9203783 A1 WO 9203783A1
Authority
WO
WIPO (PCT)
Prior art keywords
context
iproc
interrupt
service
minimal
Prior art date
Application number
PCT/US1991/004067
Other languages
English (en)
Inventor
Gregory G. Gaertner
Diane M. Wengelski
Keith J. Thompson
Original Assignee
Supercomputer Systems Limited Partnership
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
Application filed by Supercomputer Systems Limited Partnership filed Critical Supercomputer Systems Limited Partnership
Publication of WO1992003783A1 publication Critical patent/WO1992003783A1/fr

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/461—Saving or restoring of program or task context

Definitions

  • the present invention relates generally to kernel-based operating systems. More particularly, the present invention relates to a new minimal-context process entity able to perform faster and more efficiently all system-side tasks associated with Unix kernel daemons and other kernel
  • This invention is a new programmable minimal-context process able to perform any kernel function, including the efficient servicing of system interrupts and other events.
  • This background section discusses process context and servicing of interrupts as implemented in prior art kernel- based operating systems. More information about these topics is available in chapters 6 and 12 of "The Design of the UNIX Operating System,” written by Maurice J. Bach, and published in 1986 by Prentice-Hall, Inc.
  • Process context has two components, user-side context and system- side context.
  • User-side context consists of the process instructions, its data, its stack, any shared data, and the contents of any user-related registers.
  • the system-side context consists of the process table entry containing state, accounting, scheduling and general control information, internal process control information, the kernel stack, and the contents of system-related registers.
  • the kernel must save the register portion of the context of a process whenever a process is switched out of execution, and restore that portion of the context prior to the processor's resuming execution.
  • Switching register contexts can take a substantial number of processor cycles depending upon how many registers are implemented in a system archi ⁇ tecture.
  • Scalar/vector processors having several multi ⁇ function functional units usually require significant number of scalar registers, large capacity vector registers, and storage registers as do systems in which data is frequently shared. These cycles impact system performance because register context switches are done each time the system receives an interrupt, the kernel does a process switch, or when a user makes a system call.
  • the servicing of system interrupts in prior art system provides an example of a common kernel function in which a quicker and more efficient method is desired.
  • the kernel does work resulting from the arrival of an interrupt at a particular processor by stopping the process currently executing on th the processor. The work is done in the context of the currently executing process.
  • Process A is running when an interrupt occurs, for example, an I/O interrupt confirms that a disk transfer has been made to memory for process X.
  • Process A is interrupted because of process X.
  • Interrupt hardware transfers control to the zero level interrupt handling routine.
  • the interrupt handler first saves the register context of process A and sets a pointer to process A's process number to start it up again later.
  • the process A information originally stored in the stack may be moved to a temporary stack, although many prior art implementa ⁇ tions use the kernel stack.
  • the interrupt handler now wakes up process X.
  • Process X has been blocked from any other activity while it has been waiting for the interrupt handler to respond.
  • the wake up call unblocks processor X and queues it on the run queue. If there is now a higher priority process on the run queue, the interrupt handler being run by process A calls the integrated dispatcher and the highest priority process is chosen to run. This process may be process X or some other process that has been queued at a higher priority. If a higher priority process does not exist on the run queue, the interrupt handler does not invoke the integrated dispatcher. Instead, process A's context is restored and it resumes execution.
  • kernel functions such as interrupt handling in prior art systems
  • a major problem is the amount of system overhead required to perform kernel functions. Context switches and process start-up times consume processor cycles and affect the overall performance of the processor. Efficiency is reduced because of overhead associated with processes.
  • Context switches and process start-up times consume processor cycles and affect the overall performance of the processor. Efficiency is reduced because of overhead associated with processes.
  • the kernel processes contain more context information than is actually required.
  • the user-side context of kernel processes i.e., user block and various process table fields
  • user-side context does have overhead associated with memory and switching because the system automatically processes this context and unnecessarily consumes resources to do so.
  • the prior art provides a method designed to be implemented on single processor systems. Deficiencies in the prior art are apparent when a kernel function, such as interrupt handling, is implemented on multiprocessor systems. In a single processor system, the interrupt is handled by default on the only processor. In multiprocessor systems, it may be desirable to service the interrupt on a preferred processor, one one doing lower priority work, for example, or on an idle processor.
  • a process is generally defined as an entity that the operating system can schedule to run.
  • the operating system has knowledge of a process through entries in various internal data structures.
  • the present invention introduces a new type of process called an iproc.
  • An iproc is a minimal-context process designed to efficiently execute kernel tasks. Iprocs provide an efficient means of doing work created by an interrupt or other system event into a processor available to do the work.
  • An iproc can be created at the time of the event or prior to the event.
  • the inewproc procedure is called to create a minimal- context iproc in the same way the fork system call is called to create a full-context process.
  • An advantage of the present invention is that because an iproc carries only system context, an iproc requires minimal context alloca ⁇ tion/restoration as it is created/scheduled, and is there ⁇ fore quickly ready to execute.
  • An iproc is capable of doing all ranges of kernel functions from causing a message to be printed on a console screen to servicing I/O and clock interrupts.
  • An iproc is not created by fork, but instead is created by inewproc. Iprocs can be created prior to an event and put to sleep until the event actually occurs, or they can be created dynamically as needed. As it is created, an iproc is assigned only a small amount of system-side context includedin its iproc table entry, which is a minimized subset of an iproc entry. Iprocs are not allocated a user area since they never execute user code. When requested on-demand by a process, an iproc is created and switched into execution more quickly than process created by fork.
  • An iproc also terminates quicker than a fork-created process.
  • An iproc exits quickly since it does not need to do all the normal exit processing, such as closing open files, that a full- context process has to do.
  • Carrying a minimal amount of system-only context is one of the iprocs most advantageous features, and enables an iproc to switch quickly and with very low overhead. This effi ⁇ ciency is realized because the significant amounts of user register context does not exist for an iproc, and is therefore not saved and restored.
  • An advantage of the present invention is that iprocs use fewer system resources to accomplish the same work as prior art kernel processes.
  • Iproc is scheduled from the run queue. Iprocs may be scheduled by traditional means, such as sleep, wake-up calls, or their equivalent, and/or via a wake up queue on a multiprocessor computer system as described in greater detail in the previously-identified co-pending application titled METHOD OF EFFICIENT COMMUNI ⁇ CATION BETWEEN COPROCESSORS OF UNEQUAL SPEEDS.
  • iprocs can do any type of kernel processing and are not limited to servicing interrupts
  • a major advantage of iprocs is that they can be used to minimize the impact of interrupts received by a processor. This is done by enabling the process in execution when an interrupt occurs to acknowledge the interrupt and to place an iproc on the run queue to do the actual servicing of the interrupt. That is, the present invention enables the executing process to defer the interrupt to another process, an iproc, that may execute on a different processor or that could execute at a later time on the same processor. This is accomplished by implementing a zero level interrupt routine which the interrupted processor executes when it receives the interrupt. The zero-level interrupt routine does not service the interrupt.
  • the interrupted processor jumps from the process it is executing to the zero level interrupt routine and executes the code.
  • the zero level interrupt routine includes code to determine the cause of the interrupt and to cause the appropriate iproc to be scheduled. Scheduling the iproc is done either by waking a daemon iproc that was created earlier or by creating anew iproc.
  • the routines for waking or creating an iproc place the iproc onto the run queue so that the integrated dispatcher can schedule it, a process that is described in greater detail in the previously-identified co-pending application titled SCHEDULING METHOD FOR A MULTIPROCESSING OPERATING SYSTEM.
  • the executing process may not be switched out; it is interrupted for a short period and then resumes execution if it is still at a higher priority than other processes on the run queue.
  • This method prevents a low priority interrupt from causing a high priority process to be switched out of execution. Because there is only a minimal context switch when an interrupt is acknowledged, the impact of the interrupt, regardless of its priority, is minimal for the interrupted process.
  • the zero level interrupt routine only saves those few registers that it knows it will use rather than saving the processes entire context. If the current process is resumed, only a minimal context restoration is necessary. The full-context save is delayed until this process is naturally switched out.
  • Another advantage of the method of the present invention is that it enables kernel functions that service external and internal events to be scheduled into preferred processors in a multiprocessor system.
  • a preferred processor is one available to do work rather than one executing a process, or one that is executing a low priority process. This allows one process to queue an iproc on the run queue to do some kernel task and then to signal the preferred processor that there is now a more important process for it to run.
  • the signal causes the preferred processor to run the integrated dispatcher if that iproc is at a higher priority than the currently executing process.
  • the integrated dispatcher switches out the currently executing process and runs the iproc.
  • Another advantage of the present invention is that the accounting of kernel functions is kept separate from user functions and, therefore, the resources used by a process can be assigned to the correct process. That is, users are not charged for the processor time spent servicing inter ⁇ rupts.
  • the minimal-context process and zero-level interrupt routine are implemented in the operating system for a multiprocessor computer, they are not limited to this implementation.
  • the method of the present invention can be implemented in other functions and utilities that require servicing of kernel functions in a multiprocessor or a uniprocessor computer system.
  • Figure 1 is a schematic diagram showing the functional environment of the iproc.
  • Figure 2 is a process diagram showing how an I/O interrupt is serviced using an existing iproc.
  • Figure 3 is a process diagram showing how an I/O interrupt is serviced using an iproc created for this interrupt.
  • Figure 4 is a process diagram showing how a clock interrupt is serviced using a programmed iproc.
  • Figure 5 is a process diagram showing how an iproc is used to perform a non-interrupt driven coprocessor request.
  • Figure 6 is a process diagram showing how a buffer daemon iproc is used to perform a non-interrupt driven kernel function.
  • Figure 7 is a listing of the pseudo code for the inewproc procedure.
  • the preferred embodiment of the present invention is particularly useful in the servicing of interrupts and other system events in a kernel-based operating system for a multiprocessor system.
  • An iproc is a minimal-context process designed to effi ⁇ ciently execute kernel tasks. Since it only executes kernel code, it does not need user-side context and is therefore more efficient to create and switch than is a full-context kernel process. Carrying minimal context enables the iproc to complete kernel functions such as post-interrupt handling more efficiently than full-context processes are able to do.
  • the method of the present invention differed from prior art interrupt handling in which the interrupt is serviced in the processor that gets the interrupt.
  • an interz. t does not have to be handled by the process which receives the interrupt. Instead, the process executes a special zero level interrupt routine that schedules an iproc to process and handle the interrupt.
  • the address of this zero level interrupt routine is contained in the interrupt address (IAD) register. When an interrupt occurs, execution continues at the address given in the IAD register.
  • IAD interrupt address
  • the zero level interrupt routine saves a minimal context and makes runnable a daemon created earlier to specifically handle such interrupts.
  • the zero level interrupt routine restores the minimal context it had saved and the accepting process continues to execute.
  • the iproc servicing the clock interrupt is on the run queue and will execute when some processor runs the integrated dispatcher routine.
  • FIG. 1 A functional environment for the minimal-context iproc is shown in Figure 1.
  • the routine that creates an iproc is shown as inewproc 40.
  • the interrupt information contained in the IAD zero level interrupt code 50 calls inewproc 40 to create an iproc or wakes a specific iproc.
  • the newly- spawned or woken up iproc is moved t other run queue 10 by the inewproc routine 40 or by the wake-up call.
  • the processor that runs the integrated dispatcher routine 1112 when this iproc is the highest priority process in the run queue 10 will run the iproc and the interrupt will be serviced. After the iproc completes the interrupt code, it either exits or goes to sleep.
  • Kernel daemons go to sleep to wait for their designated type of interrupt. Iprocs that were created by the zero level interrupt routine exit (are discarded) when they complete their task(s). If associated with a work queue 90, the minimal-context iproc performs the series of tasks on its work queue 90, the minimal-context iproc performs the series of tasks on its work queue 90 within a single waking session. This allows a single consumer wake up to service multiple wake queue producer requests.
  • S scalar
  • the context of the interrupted process must be saved. If the interrupted process is an iproc, that context will consist of the complete S register set. The V (vector) and L (local) register sets need not be saved since they are not part of the system side context, If the interrupted process is a user process, the full context must be saved. This includes the S, V and L registers.
  • FIG. 2 shows the process of servicing an interrupt using a sleeping iproc.
  • the processor jumps to the address in the IAD control register 106 so that the currently executing process 102 stops executing its code and instead executes the zero level interrupt routine that is at the address contained in the IAD register 104 to find out where to defer the interrupt.
  • the executing process 102 issues a wake-up call 108 for the specified iproc 140, and resumes running its own program.
  • the wake-up call enters the iproc 140 onto the run queue 10. Note that the executing process 102 only acknowledge sand defers the interrupt, it is not switched out. Only a minimal context switch to run the zero level interrupt routine is necessary.
  • Iproc 140 is a programmed process given the intelligence to handle the type of interrupt that has occurred. As a kernel daemon, it is frequently called and goes to sleep after interrupt processing is completed.
  • the following activity takes place on the processor that is going to actually service the interrupt.
  • the iproc 140 remains on the run queue until some processor runs the integrated dispatcher routine 1112 and takes the iproc off the run queue 10.
  • the integrated dispatcher 1112 restores the iproc's 140 context and lets it begin executing.
  • the iproc executes its interrupt handling code 118 and then goes on to run the sleep routine 116 in which its context is saved and it is switched out. At the end of this process, the iproc is sleeping 119.
  • Figure 3 shows the activity that occurs when the interrupt is services by an iproc created on demand.
  • the processor After the interrupt signal 100 is received by processor X executing 102, the processor jumps to the address in the IAD control register 106 so that the currently executing process 102 stops executing its code and instead executes the zero level interrupt code 104 to find out where to defer the interrupt.
  • the zero level interrupt routine has been enhanced with the intelligence to call the inewproc routine 40 to create an iproc to handle this interrupt type 120.
  • the inewproc routine 40 queues 122 the newly spawned iproc 114 onto the run queue 10.
  • the following activity takes place on the processor that is going to actually service the interrupt.
  • Some processor runs the integrated dispatcher routine 1112 and takes the newly spawned iproc 114 off the run queue 10.
  • the dis ⁇ patcher 1112 loads the iproc's 114 context and lets it begin executing 124.
  • the iproc 114 executes its interrupt handling code 118 and then runs the exit routine. This terminates the iproc 114.
  • FIG. 4 is a process diagram that shows how a clock interrupt is serviced by an iproc functioning as a clock daemon.
  • Iproc 134 is a programmed process given the intelligence to handle clock interrupts. As a kernel daemon, it is frequently called and goes to sleep after each clock interrupt is completed. After the interrupt signal 130 is received by processor X, the processor jumps to the address in the IAD control register 106 so that the currently executing process 102 stops executing its code and instead executes the zero level interrupt code 104 to find out where to defer the interrupt. The executing process 102 sends a wake-up call 108 to the specified iproc 134, and resumes running its own program. Note that the executing process 102 only acknowledges and defers the interrupt; it may not be switched out. The wake-up call enters the iproc 134 onto the run queue 10.
  • the following activity takes place on the processor that is going to actually service the interrupt.
  • the iproc 134 remains on the run queue until some processor runs the integrated dispatcher routine 1112 and takes the iproc off the run queue 10.
  • the dispatcher 1112 restores the sleeping iproc 134 context and lets it begin executing 132.
  • the iproc 134 executes its clock program 136. Once the clock interrupt processing is completed, the iproc 134 runs the sleep routine 116 in which its context is saved and it is switched out. At the end of this process, the iproc 134 is sleeping 119.
  • Figure 5 is a process diagram showing how an iproc is used to perform a non-interrupt driven request from an external coprocessor.
  • a coprocessor request can range from post- interrupt processing to diagnostic integrity tests.
  • the coprocessor is able to make the request without using an interrupt by putting an entry onto the wake queue 142.
  • the integrated dispatcher calls the consume entry routine 144 to pull the coprocessor's entry from the wake queue.
  • the processor that runs the dispatcher routine 152 when the iproc is the highest priority entry in the run queue will run the iproc.
  • the iproc removes its entries from the work queue 154 and performs all of the tasks on the queue. This is an efficient method of servicing kernel tasks because numerous wake queue requests can be serviced at a low overhead cost since, once an iproc runs, it services all requests on the work queue and avoids the usual wake up/create overhead per request.
  • the iproc is programmed to either run the sleep routine or to exit 158.
  • Figure 6 is a process diagram showing how an iproc pro ⁇ grammed to function as a buffer daemon iproc is used to perform a non-interrupt driven kernel function, such as flushing the buffer cache.
  • the iproc performs the kernel function while the clock routine signals a preferred processor to execute the iproc.
  • the clock routine 160 sends a wake-up call to the iproc created earlier to function as a buffer daemon.
  • the wake up moves the buffer daemon iproc to the run queue 162.
  • the clock routine sends a signal to the preferred processor 161.
  • the preferred processor runs the integrated dispatcher code. If the buffer daemon is the highest priority process on the queue, the dispatcher restores the buffer daemon iproc context and lets the daemon start executing 164.
  • the buffer daemon executes its code and flushes the buffer cache 166. When it completes the flush, the buffer daemon goes on to run the sleep routine 116 in which its context is saved and it is switched out. At the end of this process, the buffer daemon iproc is sleeping 119.
  • Figure 7 shows the pseudo code for the inewproc procedure that creates the minimal context processes called iprocs.
  • the inewproc routine is a minimal subset of the inewproc routine called by the fork system call to create a full- context process.
  • the code in inewproc that allocates/initializes user context data structure does not exist in inewproc since iprocs do not have user-side context.
  • the exit routine is similarly stripped to remove unnecessary processing, such as closing files, deallocating the user area, and so on.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Procédé (1112, 10, 40) assurant des fonctions de noyau rapides et efficaces, comprenant les fonctions habituellement exécutées par les démons du noyau et par d'autres processus du noyau, comme celle que le service interrompt (50). Le procédé consiste à utiliser des processus à contexte minimal (40) n'acheminant que les informations relatives au système qui sont nécessaires pour effectuer la tâche pour laquelle ils ont été crées. Si on compare les processus à contexte maximal utilisés actuellement pour réaliser les fonctions de noyau, aux processus à contexte minimal (40), ces derniers sont crées rapidement et se commutent de manière économique. Si le processus à contexte minimal (40) et associé à une file d'attente de travail (90), celui-ci effectue une série de tâches (102) au cours d'une seule session d'exécution. Si aucune file d'attente (10) n'est utilisée, un processus à contexte minimal peut se réveiller et accomplir rapidement une tâche unique. Le procédé concerne globalement les systèmes d'exploitation basés sur le noyau.
PCT/US1991/004067 1990-08-23 1991-06-10 Procede de mise en ×uvre des fonctions du noyau WO1992003783A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US57195390A 1990-08-23 1990-08-23
US571,953 1990-08-23

Publications (1)

Publication Number Publication Date
WO1992003783A1 true WO1992003783A1 (fr) 1992-03-05

Family

ID=24285738

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1991/004067 WO1992003783A1 (fr) 1990-08-23 1991-06-10 Procede de mise en ×uvre des fonctions du noyau

Country Status (1)

Country Link
WO (1) WO1992003783A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2774489A1 (fr) * 1998-02-05 1999-08-06 Bull Sa Gestion des interruptions sur une plate-forme informatique
US6275749B1 (en) 1998-12-22 2001-08-14 Philips Electronics North America Corporation Interrupt-controlled thread processing
US6401155B1 (en) 1998-12-22 2002-06-04 Philips Electronics North America Corporation Interrupt/software-controlled thread processing

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3614742A (en) * 1968-07-09 1971-10-19 Texas Instruments Inc Automatic context switching in a multiprogrammed multiprocessor system
US4964040A (en) * 1983-01-03 1990-10-16 United States Of America As Represented By The Secretary Of The Navy Computer hardware executive
US4972312A (en) * 1985-11-04 1990-11-20 U.S. Philips Corporation Multiprocess computer and method for operating same having context switching in response to a peripheral interrupt
US5008812A (en) * 1988-03-18 1991-04-16 Digital Equipment Corporation Context switching method and apparatus for use in a vector processing system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3614742A (en) * 1968-07-09 1971-10-19 Texas Instruments Inc Automatic context switching in a multiprogrammed multiprocessor system
US4964040A (en) * 1983-01-03 1990-10-16 United States Of America As Represented By The Secretary Of The Navy Computer hardware executive
US4972312A (en) * 1985-11-04 1990-11-20 U.S. Philips Corporation Multiprocess computer and method for operating same having context switching in response to a peripheral interrupt
US5008812A (en) * 1988-03-18 1991-04-16 Digital Equipment Corporation Context switching method and apparatus for use in a vector processing system

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2774489A1 (fr) * 1998-02-05 1999-08-06 Bull Sa Gestion des interruptions sur une plate-forme informatique
WO1999040513A1 (fr) * 1998-02-05 1999-08-12 Bull S.A. Gestion des interruptions sur une plate-forme informatique
US6539436B2 (en) 1998-02-05 2003-03-25 Bull S.A. Management of interruptions in a computer platform
US6275749B1 (en) 1998-12-22 2001-08-14 Philips Electronics North America Corporation Interrupt-controlled thread processing
US6401155B1 (en) 1998-12-22 2002-06-04 Philips Electronics North America Corporation Interrupt/software-controlled thread processing

Similar Documents

Publication Publication Date Title
US5390329A (en) Responding to service requests using minimal system-side context in a multiprocessor environment
US5452452A (en) System having integrated dispatcher for self scheduling processors to execute multiple types of processes
US6006247A (en) Method and system for scheduling threads and handling exceptions within a multiprocessor data processing system
US9870252B2 (en) Multi-threaded processing with reduced context switching
US6223207B1 (en) Input/output completion port queue data structures and methods for using same
EP1131739B1 (fr) Traitement par lots de signaux de job dans un systeme de multitraitement
US6021425A (en) System and method for optimizing dispatch latency of tasks in a data processing system
US5257372A (en) Methods for efficient distribution of parallel tasks to slave processes in a multiprocessing system
US5613114A (en) System and method for custom context switching
US7487503B2 (en) Scheduling threads in a multiprocessor computer
US5274823A (en) Interrupt handling serialization for process level programming
US5202988A (en) System for communicating among processors having different speeds
US20050015768A1 (en) System and method for providing hardware-assisted task scheduling
EP0817047A2 (fr) Génération et livraison d'événements dans un système entrelacé à deux niveaux
JPH0969017A (ja) コンピュータ・システムの電力管理方法及び装置
US7765548B2 (en) System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock
EP0052713B1 (fr) Système de gestron des processus pour coordonner des requêtes de travail dans un système de traitement de données
Horowitz A run-time execution model for referential integrity maintenance
JP3644042B2 (ja) マルチタスク処理装置
Lamie Real-time embedded multithreading: using ThreadX and ARM
WO1992003783A1 (fr) Procede de mise en ×uvre des fonctions du noyau
WO2004061663A2 (fr) Systeme et procede pour realiser un ordonnancement de taches assiste par materiel
Rothberg Interrupt handling in Linux
WO1992003779A1 (fr) Procede assurant la communication efficace entre des coprocesseurs
JPH08314740A (ja) プロセスディスパッチ方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IT LU NL SE

122 Ep: pct application non-entry in european phase