Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts

Abstract

A multiprocessing system is disclosed. The system includes a multithreading microprocessor, including a plurality of thread contexts (TCs), each comprising a first control indicator for controlling whether the TC is exempt from servicing interrupt requests to an exception domain for the plurality of TCs, and a virtual processing element (VPE), comprising the exception domain, configured to receive the interrupt requests, wherein the interrupt requests are non-specific to the plurality of TCs, wherein the VPE is configured to select a non-exempt one of the plurality of TCs to service each of the interrupt requests, the VPE further comprising a second control indicator for controlling whether the VPE is enabled to select one of the plurality of TCs to service the interrupt requests. The system also includes a multiprocessor operating system (OS), configured to initially set the second control indicator to enable the VPE to service the interrupts, and further configured to schedule execution of threads on the plurality of TCs, wherein each of the threads is configured to individually disable itself from servicing the interrupts by setting the first control indicator, rather than by clearing the second control indicator.

Description

CROSS REFERENCE TO RELATED APPLICATION(S) [0001] This application is a continuation-in-part (CIP) of the following co-pending Non-Provisional U.S. patent applications, which are hereby incorporated by reference in their entirety for all purposes: Ser. No.(Docket No.)Filing DateTitle11 / 313,272Dec. 20, 2005SOFTWARE EMULATION(MIPS.0214-00-US)OF DIRECTEDEXCEPTIONS IN AMULTITHREADINGPROCESSOR11 / 313,296Dec. 20, 2005PREEMPTIVE(MIPS.0214-01-US)MULTITASKINGEMPLOYING SOFTWAREEMULATION OFDIRECTED EXCEPTIONSIN A MULTITHREADINGPROCESSOR[0002] Each of the two above co-pending Non-Provisional U.S. patent applications is a continuation-in-part (CIP) of the following co-pending Non-Provisional U.S. patent application, which is hereby incorporated by reference in its entirety for all purposes: Ser. No.(Docket No.)Filing DateTitle10 / 929,097Aug. 27, 2004APPARATUS,(MIPS.0194-00-US)METHOD, ANDINSTRUCTIONFOR SOFTWAREMANAGEMENTOF MULTIPLECOMPUTATIONALCONTEXTS IN AMULTITHREADEDMICROPROCESSOR[0003] Co-pend...

AI Technical Summary

Benefits of technology

[0028] An advantage of the present invention is that it allows an SMP operating system, configured as if it were running on a relatively large number of symmetric CPUs, to run on a multithreaded processor, because each “CPU” is associated with a thread context that is very lightweight in terms of chip area and power consumption and therefore highly scalable. The thread contexts are lightweight because they do not each comprise the entire architectural state associated with an independent symmetric CPU; rather, the thread contexts have some architectural state replicated to each of them (such as a program counter and general purpose register set), but also share much of the architectural state between them (such as a TLB and interrupt control logic), which requires modifications to the SMP operating system to enable the number of operating system CPUs be equal to the number of thread contexts. Consequently, an existing body of coarse-grain multithreading technology embodied in SMP operating systems, such as multithreading telematics, robotics, or multimedia applications, may be exploited on such a highly scalable processor core.

is that it allows an SMP operating system, configured as if it were running on a relatively large number of symmetric CPUs, to run on a multithreaded processor, because each “CPU” is associated with a thread context that is very lightweight in terms of chip area and power consumption and therefore highly scalable. The thread contexts are lightweight because they do not each comprise the entire architectural state associated with an independent symmetric CPU; rather, the thread contexts have some architectural state replicated to each of them (such as a program counter and general purpose register set), but also share much of the architectural state between them (such as a TLB and interrupt control logic), which requires modifications to the SMP operating system to enable the number of operating system CPUs be equal to the number of thread contexts. Consequently, an existing body of coarse-grain multithreading technology embodied in SMP operating systems, such as multithreading telematics, robotics, or multimedia applications, may be exploited on such a highly scalable processor core.

Problems solved by technology

However, the performance improvement that may be achieved through exploitation of instruction-level parallelism is limited.

One example of a performance-constraining issue addressed by multithreading microprocessors is the fact that accesses to memory outside the microprocessor that must be performed due to a cache miss typically have a relatively long latency.

Consequently, some or all of the pipeline stages of a single-threaded microprocessor may be idle performing no useful work for many clock cycles.

Other examples of performance-constraining issues addressed by multithreading microprocessors are pipeline stalls and their accompanying idle cycles due to a data dependence; or due to a long latency instruction such as a divide instruction, floating-point instruction, or the like; or due to a limited hardware resource conflict.

The cost of replicating the architectural state for the additional logical processor in the Xeon in terms of additional chip size and power consumption is almost 5%.

Examples of common exceptions include a page fault, a divide by zero, a faulty address generated by the program, a bus error encountered by the processor when attempting to read a memory location, or an invalid instruction exception caused by an invalid instruction opcode or invalid instruction operand.

Thus, although there is an architected means for a thread context to direct an asynchronous exception to a VPE, the thread context cannot specify to the VPE which thread context should handle the exception within the VPE in a MIPS MT ASE processor, i.e., the exception architecture does not provide an explicit way for the thread context to direct an asynchronous exception to a specific other thread context.

This is a problem, particularly with MP operating systems, such as Linux SMP, that rely on the ability of one CPU to direct an inter-processor interrupt to another CPU in response to a timer interrupt request in order to accomplish preemptive multitasked process scheduling.

However, the existing MP operating systems do not have knowledge of the MIPS MT VPE / TC hierarchy, and in particular because a MIPS MT thread context is much more lightweight than a MIPS MT VPE and does not provide all the architectural state of a VPE, the existing MP operating systems do not view a MIPS MT core having M thread contexts as an M CPU system.

Images