D. Stodolsky, J.B. Chen, and B.N. Bershad. "Fast Interrupt Priority Management in Operating System Kernels". In Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures, pages 105--110, San Diego, CA, September 20--21, 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Both calls take only a few cycles to execute in the fast case; the latter call traps into the kernel if an active message arrived during the atomic section. This mechanism is similar to one suggested by von Eicken in his thesis [94] it is also similar to a mechanism described by Stodolsky et al. [90]. 4.1.3 Ideal Alewife Some of my measurements are on an ideal Alewife machine. In particular, Section 7.2.2 describes the presumed costs of data migration and computation migration on such a machine. Those measurements assume the following two changes that will be in the respin of the CMMU: ....

D. Stodolsky, J.B. Chen, and B.N. Bershad. "Fast Interrupt Priority Management in Operating System Kernels". In Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures, pages 105--110, San Diego, CA, September 20--21, 1993.

....running in a handler. The CM 5 did not provide user level access to the interrupt mask. Therefore, relative expensive kernel traps were required to both disable and re enable interrupts. Instead, Blizzard CM 5 used a software interrupt masking scheme similar to one proposed by Stodolsky, et al. SCB93] The key observation is that interrupts occur much less frequently than critical sections, so you should optimize for this common case. This approach used a software flag to mark critical sections. The lowest level interrupt handler checked this software disable flag. If it was set, the ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast interrupt priority management in operating systems. In Second USENIX Symposium on Microkernels and Other KernelArchtitectures, pages 105-110, September 1993. San Diego, CA. 203

....or 500 s with a 5ns processor clock) The achievable value we use is 500 processor cycles, which results in a cost of 1000 cycles for a null interrupt. This choice is significantly more aggressive than what current operating systems provide. However it is achievable with fast interrupt technology [21]. We use it as the achievable value when varying other parameters to ensure that interrupt cost does not swamp out the effects of varying those parameters. To capture the effects of each parameter separately, we keep the other parameters fixed at their achievable values. Where necessary, we also ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20-21, 1993, San Diego, California, USA, pages 105-110, Berkeley, CA, USA, Sept. 1993. USENIX.

....slow [TL94] and would be prohibitive for fine grain parallel applications. Masking unmasking interrupts may also require invoking system calls which incur high overheads. The operating system, however, can be customized to provide low overhead user level interrupt masking schemes [SFL 94,SCB93] Systems may also provide a hybrid of polling and interrupt mechanisms. To eliminate polling across the memory bus into a peripheral device, a processor can poll on a useraccessible cachable memory location instead. By customizing the network interface 39 device driver, a low level interrupt ....

....on the memory bus. A memory mapped interrupt arbiter device distributes interrupts among the processors in a round robin fashion. To avoid invoking high overhead system calls for masking unmasking interrupts in a critical section the system uses a low overhead software interrupt masking scheme [SCB93] Each computation thread is assigned a user and system accessible flag in memory to set and reset upon entering and exiting a critical section. When an interrupt arrives in the middle of a critical section (determined by checking the flag) the system sets an interrupt pending flag and masks ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast interrupt priority management in operating systems. In Second USENIX Symposium on Microkernels and Other Kernel Archtitectures, pages 105--110, September 1993. San Diego, CA. 126

....an interrupt. The achievable value we use is 500 processor cycles, which results in a cost of 1000 cycles for a null interrupt. This choice is significantly more aggressive (about a factor of 4) than what current operating systems provide. However it is achievable with fast interrupt technology [51]. We use it as the achievable value when varying other parameters to ensure that interrupt cost does not swamp out the e#ects of varying those parameters. Table 1 summarizes the achievable values of each parameter. Parameter Range Achievable Best Host Overhead (cycles) 0 10000 600 #0 I O Bus ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20--21, 1993, San Diego, California, USA, pages 105--110, Berkeley, CA, USA, September 1993. USENIX.

....an order of magnitude faster than load linked storeconditionally, operations for disabling interrupts are usually privileged, meaning that they cannot be directly invoked by user processes. It is also the case that support for hierarchical priority levels is more expensive than one might hope [9]. Because of the limitations of these two hardware based approaches, Bershad, Redell, and Ellis have proposed a software only implementation of mutual exclusion on uniprocessors [10] However, the solution is applicable only to simple atomic sequences that involve at most one write to shared ....

....different from achieving mutual exclusion, the implementation the authors describe is not limited to Scheduler Activations. The paper gives only a superficial treatment of the issues involved. It does not give any indications as to the cost or limitations of rollforward. Finally, Stodolsky et al. [9] present a technique called optimistic interrupt protection. The idea is to use delayed (lazy) evaluation to reduce the number of times that expensive interrupt level changing instructions have to be invoked. It is interesting to note that the implementation of this technique is one particular ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad, `Fast interrupt priority management in operating system kernels', Proceedings of the Second Usenix Workshop on Microkernels and Other Kernel Architectures. Usenix, September 1993, pp. 105--110.

....an interrupt only if the host does not poll before the timer expires. LCI s polling watchdog cooperates with LCI s networkinterrupt management mechanism. Recall that LCI clients may dynamically disable and enable network interrupts. For efficiency, LCI uses optimistic interrupt protection [14]: lci intr disable( and lci intr enable( toggle the interrupt status flag in host memory, without synchronizing with the NI, the source of network interrupts. Consequently, the NI may generate an interrupt after the host called lci intr disable( The kernel will then dispatch a signal to the ....

D. Stodolsky, J. Chen, and B. Bershad. Fast Interrupt Priority Management in Operating Systems. In Proc. of the USENIX Symposium on Microkernels and Other Kernel Architectures, pages 105--110, San Diego, Sept. 1993.

....Modified for Optimistic Critical Sections . 17 B.2.1 Interrupt Handler Stub Macros . 17 B.2.2 Recover Table . 22 3 1 Introduction The optimistic scheme we have implemented was proposed by Stodolsky et al. [3] as a way to reduce the overhead incurred by masking interrupts in hardware. On some architectures, this overhead can be substantial, especially if communication with an off processor interrupt controller is required. In their design, upon entering a critical section, we set an interrupt mask in ....

.... of Optimistic Critical Sections The basic design is to use a global flag to indicate that we are in a critical section, and if we get interrupted, let the interrupt handler stub detect the problem, disable interrupts, and arrange for us to handle the interrupt when we exit the critical section [3]. To implement this design, we modify the interrupt handler stubs and write four new macros: opt sti( opt cli( opt save flags(x) and opt restore flags(x) To simplify the implementation of the design, as much of the work as possible is left to the interrupt handler stubs. Since the hardware ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad. "Fast Interrupt Priority Management in Operating System Kernels," pp. 105-110, USENIX Symposium on Microkernels and Other Kernel Architectures, San Diego, CA (1993).

....AU writes within a cache line are combined in the NI to reduce the number of packets. Issuing an interprocessor interrupt costs 500 processor cycles, and invoking the handler is another 500 cycles. This is aggressive compared to what current operating systems provide, but is implementable [28] and prevents interrupt cost from swamping out the e#ects of other system parameters [5] The page size is 4 KBytes, and the cost to access the TLB from a handler running in the kernel is 50 processor cycles. Each protocol handler is charged a cost depending on the work it does. The cost of ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20--21, 1993, San Diego, California, USA, pages 105-- 110, Berkeley, CA, USA, Sept. 1993. USENIX.

....information, e.g. interrupt masks, to an NI through CDRs. Changing control information, such as masking NI interrupts, can be expensive in modern processors this may require an uncached store, a write buffer flush, and a trip through the operating system. To avoid these costs, Stodolsky, et al. [121] proposed the optimistic interrupt protection scheme based on the assumption that interrupts are rare events for short critical sections. A derivative of this scheme is implemented in the CM 5 version of the Wisconsin Blizzard system [104] In Blizzard, the software assigns a global processor ....

David Stodolsky, J. Bradley Chen, and Brian N. Bershad. Fast Interrupt Priority Management in Operating System Kernels. In Usenix Microkernels Workshop, 1993.

....event. 2. The HWO is written almost entirely in assembly language. The processor offers two levels of hardware interrupt IRQ and FastIRQ Arena exploits these facilities by making full use of the register optimisations offered by FastIRQ mode. handlers respectively is described in Stodolsky [10], and a method called optimistic interrupt protection based on interruptable event handling is described; but the authors do not offer a method of effectively combining both approaches as does Arena. Within the HWO, Arena treats interrupts as threads for the purpose of synchronisation (and does ....

D.Stodolsky, J.Chen & B.Bershad. Fast Interrupt Priority Management in Operating System Kernels. Proc. Usenix Symposium on Microkernels and Other Kernel Architectures, San Diego, USA. pp 105-110. 1993.

....a cache line are combined in the network interface to reduce the number of packets. Issuing an Interprocessor Interrupt (IPI) costs 500 processor cycles, and invoking the handler is another 500 cycles. This is aggressive compared to what current operating systems provide, but is implementable [25] and prevents interrupt cost from swamping out the effects of other system parameters. The page size is 4 KBytes, and the cost to access the TLB from a handler running in the kernel is 50 processor cycles. In accordance with simple experiments, the cost of creating and applying a diff in HLRC is ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20--21, 1993, San Diego, California, USA, pages 105-- 110, Berkeley, CA, USA, Sept. 1993. USENIX.

....AU writes within a cache line are combined in the NI to reduce the number of packets. Issuing an interprocessor interrupt costs 500 processor cycles, and invoking the handler is another 500 cycles. This is aggressive compared to what current operating systems provide, but is implementable [28] and prevents interrupt cost from swamping out the effects of other system parameters [5] The page size is 4 KBytes, and the cost to access the TLB from a handler running in the kernel is 50 processor cycles. Each protocol handler is charged a cost depending on the work it does. The cost of ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20--21, 1993, San Diego, California, USA, pages 105-- 110, Berkeley, CA, USA, Sept. 1993. USENIX.

....if the runtime system is in a critical section and simply return without doing anything if this is the case. Such optimistic interrupt processing schemes have also been proposed elsewhere, e.g. as a way to reduce the costs associated with interrupt priority management in operating system kernels [18]. However, the Polling Watchdog adds an additional degree of flexibility, because more interrupts will automatically be generated at Twdog intervals until the message has been handled. It is therefore not necessary for the interrupt handler to keep track of each individual network event. Instead, ....

....such as inlining polling code into the application. These restrictions could be removed by letting the run time system set a global flag whenever watchdog interrupts should be disabled. On many machines this would still be significantly cheaper than having to manipulate the hardware interrupt mask [18]. 3.3 EARTH MANNA S Implementation In spite of the simplicity of the Polling Watchdog, such a mechanism is not available in current hardware. In EARTHMANNA S, the Polling Watchdog would ideally be implemented in the network interface chip. Since our EARTH hardware development is still ongoing, ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad, "Fast Interrupt Priority Management in Operating System Kernels," in Proc. of the 2nd Usenix Symposium on Microkernels and other Kernel Architectures, 1993.

....an order of magnitude faster than load linked store conditionally, operations for disabling interrupts are usually privileged, meaning that they cannot be directly invoked by user processes. It is also the case that support for hierarchical priority levels is more expensive than one might hope [SCB93]. Because of the limitations of these two hardware based approaches to implementing atomic sequences, Bershad, Redell, and Ellis have proposed a software only implementation of mutual exclusion on uniprocessors [BRE92] However, their solution is applicable only to simple atomic sequences those ....

....mutual exclusion, the implementation the authors describe is not limited to Scheduler Activations. Unfortunately, the paper gives only a superficial treatment of the issues involved with rollforward. It does not give any indications as to the cost or limitations of the technique. Finally, [SCB93] presents a technique called optimistic interrupt protection. The idea is to use delayed (lazy) evaluation to reduce the number of times that expensive interrupt level changing instructions have to be invoked. What is interesting is that the implementation of this technique is one particular ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad. Fast interrupt priority management in operating system kernels. In Proceedings of the Second Usenix Workshop on Microkernels and Other Kernel Architectures, pages 105--110. Usenix, September 1993.

.... Message Size (bytes) Large Message Throughput DMA G G G G G G G G G INT ; LANai n n n n n n n n n Typhoon 0 5 5 5 5 5 5 5 5 12 7 SMP Nodes Systems that run on uniprocessors can implement critical sections in protocol handlers surpressing interrupts, either in software [35] or hardware. These mechanisms do not work for multiprocessors in which the second processor runs the protocol. Blizzard ensures mutual exclusion with locks, which complicated the atomicity of a software or ECC access control test and the subsequent reference. 7.1 Blizzard S In Blizzard S, the ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast Interrupt Priority Management in Operating Systems. In Second USENIX Symposium on Microkernels and Other Kernel Archtitectures, pages 105--110, September 1993. San Diego, CA.

....registers reside in main memory, while the status and control registers reside in the ULNI device on the memory or I O bus (Figure 4) The combination of locations within a host node and ULNI registers gives rise to a variety of other 10 decoupled architectures. For example, Stodolsky, et al. s [51] optimistic interrupt protection scheme offer a decoupled ULNI architecture in which the status and control registers are mapped to a fixed global register in a processor, but data registers can reside in the I O bus ULNI device itself. When a message arrives at the ULNI device, it informs the ....

....Section 8 for more details on data movement alternatives between the processor and the ULNI device. Third, frequent processor updates to control registers can proceed very fast if they are cached in the processor s data cache. For example, we can have a better implementation of Stodolsky, et al. s [51] optimistic interrupt protection scheme (described briefly in Section 4) by using a cached memory location, instead of reserving a register 13 from the limited global register pool, to hold the control information. In the absence of any message, the ULNI does not read the control information, ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast Interrupt Priority Management in Operating Systems. In Second USENIX Symposium on Microkernels and Other Kernel Archtitectures, pages 105--110, September 1993. San Diego, CA.

....(netids) IBM 93c] The concept of a netid is introduced and explained in this section. Third we address the need for mutual exclusion within device driver critical sections and describe the technique of optimistic interrupt protection introduced by researchers at Carnegie Mellon University. Stodolsky et al. 93] The fourth technique is that of providing optimized fast paths designed to handle given specific instances more efficiently than code which supports the general case. Saving the most important for last, we finally discuss the use of shared memory to eliminate the cost of copying data between the ....

....of frames do, in fact, have the same netid as the frame which immediately proceeded them. In environments which do use multiple netids, however, the current scheme may tend to limit performance unnecessarily. 3.3. Optimistic Interrupt Protection Researchers at Carnegie Mellon University [Stodolsky et al. 93] have proposed an optimization which reduces overhead associated with assuring mutually exclusive access to critical sections of code by changing the processor interrupt level. Such interrupt level manipulation is a common technique for guaranteeing mutual exclusion. The problem with the ....

Stodolsky et. al. "Fast Interrupt Priority Management in Operating System Kernels." In Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures (San Diego, CA. Sept. 20, 21). The USENIX Association, Berkeley, CA, 1993, pp. 105-110.

....(or impossible) to disable interrupts, and work best in environments where contention is minimal. The cost and complexity of these schemes is higher than the on chip schemes we propose, and our analysis shows that under typical loads, such complexity is unnecessary. Similarly, Stodolsky et al. [Stod93] proposed decreasing the cost of synchronization by taking an optimistic approach. When the kernel makes a request to raise the global priority level, instead of communicating with the interrupt controller, the kernel saves the desired priority level in a variable. The critical section is then ....

....with the simplicity of the pessimistic schemes we describe, with the low overhead of the optimistic schemes. Comparing our scheme to those used in earlier systems, we are reminded of how quickly hardware changes: the CPU and I O bus of today is substantially faster than the one available in 1993 [Stod93], and much, much faster than the one available on the VAX or the PDP 11 [Leff89] Nevertheless, developers of newer systems [Cust93] find themselves re using old, complex techniques to solve a problem that may no longer exist. Status and Availability All code discussed in this paper (benchmark ....

Stodolsky, D., Chen, J. B., Bershad, B., "Fast Interrupt Priority Management in Operating System Kernels," USENIX Symposium on Microkernels and Other Kernel Architectures, 105--110, San Diego, CA (1993).

.... was done in the Prelude compiler to support computation migration [23] More broadly, our use of continuations is similar to the introduction of continuations into operating system structure [18] Our use of optimistic execution is also similar to work 20 REFERENCES done on interrupt handling [33]. 6 Conclusion We have described a software architecture for user level communication architectures that is designed for the compilation of high level languages. By making our source language high level, we hide low level communication issues from the user. We have described the structure of the ....

D. Stodolsky, J.B. Chen, and B.N. Bershad. "Fast Interrupt Priority Management in Operating System Kernels". In Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures, pages 105--110, San Diego, CA, September 20--21, 1993.

....hard real time OS, most notably the fact that interrupts are often disabled during the course of execution of the kernel. Other problems include time sharing scheduling, virtual memory system timing unpredictability, and lack of high granularity timers. It turns out that using software interrupts [23], together with several other techniques, it is nevertheless possible to modify Linux so as to overcome these problems. The idea to use software interrupts so that a general purpose operating system could coexist with a hard 1 http: www.linux.org 3 real time system is due to Victor Yodaiken ....

....of the kernel comes out. And even if we could cope with that, the bound could be just too high for our needs. In Real Time Linux, this problem is solved by putting a layer of emulation software between the Linux kernel and the interrupt controller hardware, a technique similar to that described in [23], but used for a different purpose. In the Linux source code all occurrences of cli, sti, and iret instructions (iret means return from interrupt) are replaced with emulating macros: S CLI, S STI and S IRET. All hardware interrupts are caught by the emulator. The idea of emulating cli and sti to ....

Daniel Stodolsky, J. Bradley Chen, and Brian Bershad. Fast interrupt priority management in operating system kernels. In The Proceedings of the 2nd USENIX Symposium on Microkernels and Other Kernel Architectures. USENIX, September 1993.

.... its performance (e.g. by eliminating SPARC register window overflows on commonlyexecuted paths) To make Tempest s message and fault handlers atomic (with respect to each other) without invoking system calls to re enable interrupts, we use an interrupt masking scheme similar to Stodolsky et al. s [24]. Critical sections set a software disable flag on entry and check a deferred interrupt flag on exit. If an interrupt encounters a software disable flag, the handler queues the interrupt and sets the deferredinterrupt flag. Tempest s active messages are more general than those in CMAML ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast Interrupt Priority Management in Operating Systems. In Second USENIX Symposium on Microkernels and Other Kernel Archtitectures, pages 105--110, September 1993. San Diego, CA.

....500 s with a 5ns processor clock) The achievable value we use is 500 processor cycles, which results in a cost of 1000 cycles for a null interrupt. This choice is significantly more aggressive than what current operating systems provide. However it is achievable with fast interrupt technology [21]. We use it as the achievable value when varying other parameters to ensure that interrupt cost does not swamp out the effects of varying those parameters. To capture the effects of each parameter separately, we keep the other parameters fixed at their achievable values. Where necessary, we also ....

D. Stodolsky, J. B. Chen, and B. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Association, editor, Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures: September 20--21, 1993, San Diego, California, USA, pages 105--110, Berkeley, CA, USA, Sept. 1993. USENIX.

....to work in environments where it is expensive (or impossible) to disable interrupts. The cost and complexity of these schemes is higher than the on chip schemes we propose, and our analysis shows that under typical loads, such complex techniques are unnecessary. Similarly, Stodolsky et al. [Stod93] proposed decreasing the cost of synchronization by taking an optimistic approach. When the kernel makes a request to raise the global priority level, instead of communicating with the interrupt controller, the kernel saves the desired priority level in a variable. The critical section is then ....

....with the simplicity of the pessimistic schemes we describe, with the low overhead of the optimistic schemes. Comparing our scheme to those used in earlier systems, we are reminded of how quickly hardware changes: the CPU and I O bus of today is substantially faster than the one available in 1993 [Stod93], and much, much faster than the one available on the VAX or the PDP 11 [Leff89] Nevertheless, developers of newer systems [Cust93] find themselves re using old, complex techniques to solve a problem that may no longer exist. Status and Availability All code discussed in this paper, including ....

Stodolsky, D., Chen, J. B., Bershad, B., "Fast Interrupt Priority Management in Operating System Kernels," USENIX Symposium on Microkernels and Other Kernel Architectures, 105--110, San Diego, CA (1993).

.... contiguous, for example by temporary mapping[23] Changing the interrupt priority level (IPL) is done four times on the switching path due to scheduler involvement, but not at all on the migrating path; while IPL changes are cheap on the PA RISC, they are very expensive on some other architectures[28], making migrating threads especially important on them. The unavoidable cost of address space switching is much higher on some architectures, which would lead to a lower improvement ratio, but even then we expect the benefits to be considerable. 8.4 Micro and Macro Benchmark Results ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad. Fast interrupt priority management in operating system kernels. In Proc. of the Second USENIX Workshop on Micro-kernels and Other Kernel Architectures, San Diego, CA, September 1993.

....sure it cannot deadlock with the processor it interrupted. Unfortunately, our hardware only provides the ability to enable and disable all interrupts, and for a number of reasons the HURRICANE kernel always runs with interrupts on. We therefore adapted a strategy first suggested by Stodolsky et al. [23]. Inter processor interrupts are treated as a separate interrupt class that can be logically masked. A per processor flag is set whenever a lock is about to be acquired that could cause deadlock with an interrupt handler. An interrupt handler always first checks the flag, and if clear, can safely ....

Daniel Stodolsky, J. Bradley Chen, and Brian N. Bershad. Fast interrupt priority management in operating system kernels. In USENIX Microkernels Workshop. USENIX, 1993.

....provide user level access to the interrupt mask, so it requires expensive Appears in: ASPLOS VI, Oct. 1994. Reprinted by permission of ACM. kernel traps to both disable and re enable interrupts. Instead, we use a software interrupt masking scheme similar to one proposed by Stodolsky, et al. [35]. The key observation is that interrupts occur much less frequently than critical sections, so we should optimize for this common case. This approach uses a software flag to mark critical sections. The lowest level interrupt handler checks this softwaredisable flag. If it is set, the handler ....

Daniel Stodolsky, J. Brad Chen, and Brian Bershad. Fast Interrupt Priority Management in Operating Systems. In Second USENIX Symposium on Microkernels and Other Kernel Archtitectures, pages 105--110, September 1993. San Diego, CA.

....at none. For this reason, many research and commercial systems have been modified to address performance problems caused by a particular application s needs, such as interprocess communication, synchronization, thread management, networking, virtual memory, and cache management [DBRD91, BRE92, SBC93, Ber93, YBMM94, MB93, Fel92, YTR 87, HC91, MA90, ABLL92, FP93, WB92, RLB94, ROKB95] For example, most improvements in IPC performance have been motivated by database applications or operating system servers. Each change required careful and deliberate modifications of the operating system ....

Daniel Stodolsky, Brian N. Bershad, and Brad Chen. Fast Interrupt Priority Management for Operating System Kernels. In Proceedings of the 2nd Usenix Workshop on Microkernels and Other Kernels, September 1993.

.... the last several years that has addressed some of the fundamental performance problems that arise in modern operating system services, including interprocess communication, synchronization, thread management, networking, virtual memory, and cache management [Draves et al. 91, Bershad et al. 92, Stodolsky et al. 93, Bershad 93, Yuhara et al. 94, Maeda Bershad 93, Thekkath et al. 93, Felten 92, Young 89, McNamee Armstrong 90, Anderson et al. 92, Wheeler Bershad 92] In each case, the interfaces exported by a service were poorly matched to the needs of important applications. The solution to the ....

....Synchronization Synchronization mechanisms coordinate the activity of multiple threads of control that share memory. Synchronization mechanisms that assume no contention for shared resources can have lower overhead than pessimistic ones that assume that contention will occur [Massalin Pu 89, Stodolsky et al. 93] In the general case, these optimistic strategies require some form of kernel support to ensure correctness in the presence of an oblivious kernel scheduler [Bershad et al. 92, Bershad 93, Alemany Felten 92] SPIN will make arbitrary synchronization strategies possible by reflecting scheduling ....

Stodolsky, D., Bershad, B. N., and Chen, B. Fast Interrupt Priority Management for Operating SystemKernels. In Proceedings of the Second Usenix Workshop on Microkernels and Other Kernel Architectures, September 1993.

....years that has addressed some of the fundamental performance problems that arise in modern operating system services. This research includes interprocess communication [Bershad et al. 90, Draves et al. 91] synchronization [Bershad et al. 92, Bershad 93] thread management [Anderson et al. 92, Stodolsky et al. 93] networking [Maeda Bershad 93, Yuhara et al. 94, Thekkath et al. 93, Felten 92] virtual memory [Young 89, McNamee Armstrong 90] and cache management [Wheeler Bershad 92] In each case, the interfaces exported by a service were poorly matched to the needs of important applications. The ....

Stodolsky, D., Bershad, B. N., and Chen, B. Fast Interrupt Priority Management for Operating System Kernels. In Proceedings of the Second Usenix Workshop on Microkernels and Other Kernel Architectures, September 1993.

No context found.

Stodolsky, D., J.B. Chen, and B.N. Bershad. Fast Interrupt Priority Management in Operating Systems Kernels. Technical Report CMU-CS-93-152, School of Computer Science, Carnegie Mellon University, May, 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC