Abstract: A technique to monitor software thread performance and update software that issues or uses the thread(s) to reduce performance-inhibiting events. At least one embodiment of the invention uses hardware and/or software timers or counters to monitor various events associated with executing user-level threads and report these events back to a user-level software program, which can use the information to avoid or at least reduce performance-inhibiting events associated with the user-level threads.

Abstract: A first execution time of a first thread executing on a first processing unit of a multiprocessor is determined. A second execution time of a second thread executing on a second processing unit of the multiprocessor is determined, the first and second threads executing in parallel. Power is set to the first and second processing units to effectuate the first and second threads to finish executing at approximately the same time in future executions of the first and second threads. Other embodiments are also described and claimed.

Abstract: Method, apparatus and system embodiments to schedule OS-independent “shreds” without intervention of an operating system. For at least one embodiment, the shred is scheduled for execution by a scheduler routine rather than the operating system. A scheduler routine may run on each enabled sequencer. The schedulers may retrieve shred descriptors from a queue system. The sequencer associated with the scheduler may then execute the shred described by the descriptor. Other embodiments are also described and claimed.

Abstract: Methods, data structures, instructions, and techniques for structured exception handling for user-level threads in a multi-threading system are provided. Registered filter routines may be dispatched to a thread unit not managed by the operating system (OS). The dispatch may occur by allowing an OS-managed thread unit (proxy) to invoke the OS-provided structured exception handling service (including dispatcher) on behalf of the sequestered thread unit. Alternatively, an OS-managed thread unit may include dispatch code and may, without OS intervention, dispatch the filter routine to the sequestered thread unit. Other embodiments are also described and claimed.

Abstract: Method, apparatus and system embodiments to schedule OS-independent “shreds” without intervention of an operating system. For at least one embodiment, the shred is scheduled for execution by a scheduler routine rather than the operating system. A scheduler routine may run on each enabled sequencer. The schedulers may retrieve shred descriptors from a queue system. The sequencer associated with the scheduler may then execute the shred described by the descriptor. Other embodiments are also described and claimed.

Abstract: Embodiments of the invention provide a method of creating, based on an operating-system-scheduled thread running on an operating-system-visible sequencer and using an instruction set extension, a persistent user-level thread to run on an operating-system-sequestered sequencer independently of context switch activities on the operating-system-scheduled thread. The operating-system-scheduled thread and the persistent user-level thread may share a common virtual address space. Embodiments of the invention may also provide a method of causing a service thread running on an additional operating-system-visible sequencer to provide operating system services to the persistent user-level thread. Embodiments of the invention may further provide apparatus, system, and machine-readable medium thereof.

Abstract: In an embodiment, a method is provided. The method includes managing user-level threads on a first instruction sequencer in response to executing user-level instructions on a second instruction sequencer that is under control of an application level program. A first user-level thread is run on the second instruction sequencer and contains one or more user level instructions. A first user level instruction has at least 1) a field that makes reference to one or more instruction sequencers or 2) implicitly references with a pointer to code that specifically addresses one or more instruction sequencers when the code is executed.

Abstract: Operating system services are transparently triggered for thread execution resources (“sequencers”) that are sequestered from view of the operating system. A “surrogate” thread that is managed by, and visible to, the operating system is utilized to acquire OS services on behalf of a sequestered sequencer. Multi-shred contention for shred-specific resources may thus be alleviated. Other embodiments are also described and claimed.

Abstract: In one embodiment, the present invention includes a method for directly communicating between an accelerator and an instruction sequencer coupled thereto, where the accelerator is a heterogeneous resource with respect to the instruction sequencer. An interface may be used to provide the communication between these resources. Via such a communication mechanism a user-level application may directly communicate with the accelerator without operating system support. Further, the instruction sequencer and the accelerator may perform operations in parallel. Other embodiments are described and claimed.

Abstract: Embodiments of the invention provide a method of creating, based on an operating-system-scheduled thread running on an operating-system-visible sequencer and using an instruction set extension, a persistent user-level thread to run on an operating-system-sequestered sequencer independently of context switch activities on the operating-system-scheduled thread. The operating-system-scheduled thread and the persistent user-level thread may share a common virtual address space. Embodiments of the invention may also provide a method of causing a service thread running on an additional operating-system-visible sequencer to provide operating system services to the persistent user-level thread. Embodiments of the invention may further provide apparatus, system, and machine-readable medium thereof.

Abstract: Method, apparatus and system embodiments to schedule user-level OS-independent “shreds” without intervention of an operating system. For at least one embodiment, the shred is scheduled for execution by a scheduler routine rather than the operating system. The scheduler routine may receive compiler-generated hints from a compiler. The compiler hints may be generated by the compiler without user-provided pragmas, and may be passed to the scheduler routine via an API-like interface. The interface may include a scheduling hint data structure that is maintained by the compiler. Other embodiments are also described and claimed.

Abstract: A first execution time of a first thread executing on a first processing unit of a multiprocessor is determined. A second execution time of a second thread executing on a second processing unit of the multiprocessor is determined, the first and second threads executing in parallel. Power is set to the first and second processing units to effectuate the first and second threads to finish executing at approximately the same time in future executions of the first and second threads. Other embodiments are also described and claimed.

Abstract: A first execution time of a first thread executing on a first processing unit of a multiprocessor is determined. A second execution time of a second thread executing on a second processing unit of the multiprocessor is determined, the first and second threads executing in parallel. Power is set to the first and second processing units to effectuate the first and second threads to finish executing at approximately the same time in future executions of the first and second threads. Other embodiments are also described and claimed.

Abstract: A technique to monitor software thread performance and update software that issues or uses the thread(s) to reduce performance-inhibiting events. At least one embodiment of the invention uses hardware and/or software timers or counters to monitor various events associated with executing user-level threads and report these events back to a user-level software program, which can use the information to avoid or at least reduce performance-inhibiting events associated with the user-level threads.

Abstract: Embodiments of the invention provide a method of creating, based on an operating-system-scheduled thread running on an operating-system-visible sequencer and using an instruction set extension, a persistent user-level thread to run on an operating-system-sequestered sequencer independently of context switch activities on the operating-system-scheduled thread. The operating-system-scheduled thread and the persistent user-level thread may share a common virtual address space. Embodiments of the invention may also provide a method of causing a service thread running on an additional operating-system-visible sequencer to provide operating system services to the persistent user-level thread. Embodiments of the invention may further provide apparatus, system, and machine-readable medium thereof.

Abstract: Data structure creation, organization and management techniques for data local to user-level threads are provided. In one embodiment, a method includes generating, for a user-level thread (“shred”) to run on a thread unit that is not managed by an operating system (“OS”), a storage area for local data and maintaining state in the storage area across a context switch from the thread unit that is not managed by the OS to a second thread unit that is managed by the OS. Other embodiments are also described and claimed.

Abstract: In one embodiment, the present invention includes a method for receiving a request from a user-level agent for programming of a user-level privilege for at least one architectural resource of an application-managed sequencer (AMS) and programming the user-level privilege for the at least one architectural resource using an operating system-managed sequencer (OMS) coupled to the AMS. Other embodiments are described and claimed.

Abstract: Embodiments of the invention provide a method of creating, based on an operating-system-scheduled thread running on an operating-system-visible sequencer and using an instruction set extension, a persistent user-level thread to run on an operating-system-sequestered sequencer independently of context switch activities on the operating-system-scheduled thread. The operating-system-scheduled thread and the persistent user-level thread may share a common virtual address space. Embodiments of the invention may also provide a method of causing a service thread running on an additional operating-system-visible sequencer to provide operating system services to the persistent user-level thread. Embodiments of the invention may further provide apparatus, system, and machine-readable medium thereof.

Abstract: A technique to monitor software thread performance and update software that issues or uses the thread(s) to reduce performance-inhibiting events. At least one embodiment of the invention uses hardware and/or software timers or counters to monitor various events associated with executing user-level threads and report these events back to a user-level software program, which can use the information to avoid or at least reduce performance-inhibiting events associated with the user-level threads.

Abstract: An air/fuel imbalance detection module includes a fueling control module, a response time determination module, and a comparison module. The fueling control module commands a fueling change according to a predetermined fueling pattern. The response time determination module determines a measured response time for a wide-range air/fuel sensor (WRAF) to output a predetermined voltage. The comparison module compares the measured response time with a reference time range and diagnoses air/fuel imbalance when the measured response time is outside the reference time range.