|Publication number||US7493435 B2|
|Application number||US 10/681,446|
|Publication date||Feb 17, 2009|
|Filing date||Oct 6, 2003|
|Priority date||Oct 6, 2003|
|Also published as||CN1890634A, CN1890634B, DE112004001887B4, DE112004001887T5, US20050086547, WO2005038652A1|
|Publication number||10681446, 681446, US 7493435 B2, US 7493435B2, US-B2-7493435, US7493435 B2, US7493435B2|
|Inventors||Grant H. Kobayashi, Barnes Cooper|
|Original Assignee||Intel Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (40), Non-Patent Citations (1), Referenced by (13), Classifications (9), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates to the field of computer systems and, in particular, to system management mode optimizations.
Computer systems are becoming increasingly pervasive in our society including everything from small handheld electronic devices, such as personal digital data assistants and cellular phones, to application-specific electronic components, such as set-top boxes and other consumer electronics, to full mobile, desktop, and server systems. However, as systems become smaller in size and in price, the need for efficient memory allocation and system management becomes more important.
Server systems have been traditionally characterized by a significant amount of conventional memory and multiple physical processors in the same system (a multiprocessor system), wherein a physical processor refers to a single processor die or single package. The significant amount of memory available to a server system has lead to extremely inefficient allocation of memory space and wasted execution time.
Typically, in a multi-processor system, upon boot every processor arbitrates for wake-up, which may include allocating memory and relocating the processor's base address (SMBase). In the process of initializing each processor, a system management interrupt (SMI) is generated, which is handled with a default SMI handler for each processor. Usually, the processors arbitrate with a race to the flag scheme, wherein the first processor to begin handling the SMI is able to begin initialization. Initialization typically includes allocation of a separate and distinct 4 kB aligned memory space for each processor, which forces one to allocate more memory than needed for system management.
Furthermore, when a system management interrupt (SMI) occurs, whether during boot or regular operation, each processor in a multiprocessor system runs a separate and distinct SMI handler to service/handle the SMI. There are two types of SMIs. The first type is an asynchronous interrupt that may be generated by the system hardware, such as when a battery is low. An asynchronous interrupt may be handled separately by any processor, since knowledge of another processor's save state area is not needed to service the request. The second type of interrupt, a synchronous SMI, that is software generated, should be handled by every processor. Typically, a software generated SMI occurs when the operating system (OS) wants a processor to enter system management mode (SMM). SMM is an environment for executing software routines/handlers that does not interfere with the OS or application programs.
In current multiprocessor systems, each processor enters SMM and then one-by-one executes a distinct SMI handler to check their registers to find out which processor generated the SMI. This requires a separate SMI handler be executed for each processor, which introduces resource contention issues, thus making updates to the SMI handler code difficult.
However, these inefficient methods of initialization and handling are not limited to multiprocessor server systems, but exist in other systems, such as mobile multiprocessor systems. Hyper-Threading Technology (HT) is a technology from Intel.RTM. Corporation of Santa Clara, Calif. that enables execution of threads in parallel using a single physical processor. HT incorporates two logical processors on one physical processor (the same die). A logical processor is an independent processor visible to the operating system (OS), capable of executing code and maintaining a unique architectural state from other processor in a system. HT is achieved by having multiple architectural states that share one set of execution resources.
Therefore, HT enables one to implement a multi(logical)processor system in a mobile platform. As shown above, inefficient memory allocation, processor initialization, and SMI handling exist in traditional multiprocessor systems, such as server systems. Furthermore, as multiprocessor systems begin to infiltrate the mobile realm, where resources such as memory are limited, the need for optimizations of the aforementioned inefficiencies becomes even more important.
A method and apparatus for efficient memory allocation and system management interrupt handling is herein described. In one embodiment, a single SMI is used to initialize each processor in a multi-processor environment. In addition, a location of a default SMI handler may be used as a wake-up vector to inactive processors to efficiently utilize memory. In another embodiment, unified handler code is executed on multiple processors to handle software generated SMIs.
The present invention is illustrated by way of example and not intended to be limited by the figures of the accompanying drawings.
In the following description, numerous specific details are set forth such as examples of specific memory addresses, memory sizes, and component configurations in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice the present invention. In other instances, well known components or methods, such as routine boot-up blocks (e.g. power on self-test (POST)), specific system management mode (SMM) implementation, and specific system management interrupt handler code have not been described in detail in order to avoid unnecessarily obscuring the present invention.
The method and apparatus described herein are for optimization of memory allocation when waking a processor and optimization of system management interrupt (SMI) handling in multiprocessor systems. The method of waking a processor may occur as a result of any number of normal operations. For example, when the computer is powered on or reset, one may wake an inactive/sleeping processor. Furthermore, when a system is returning from a low power state, such as sleep, standby, suspend, hibernation, wait-for-SIPI, sleep, deep sleep, reset, or any other mode where the second processor does not respond to interrupts one may wake an inactive processor.
It is readily apparent to one skilled in the art, that the method disclosed for waking a second processor may be applicable to any level computer system (personal digital assistants, mobile platforms, desktop platforms, and server platforms), as well as any number of processors. For example, a multiprocessor system with four or more processor may use this method to wake an inactive processor with an active processor.
Device 105 may include a first processor 120 and a second processor 125. Device 105 may be a physical processor. Device 105 may also be an embedded system or other device having at least two processors. Processors 120 and 125 may be logical processors. For example, processor 105 may include architecture state registers 130 and 135 that each holds a unique architecture state. It is readily apparent that device 105 may include more than two logical processors that each have an architecture state register associated with it to hold a separate architecture state. The two processors 120 and 125 share the same execution resources 140, caches 145, busses 115/150, and memory 155.
Device 105 may also include controller 110. Controller 110 may be an Advanced Programmable Interrupt Controller (APIC) controller. Controller 110 may be used to generate a system management interrupt (SMI). Controller 110 may also be used to communicate on an APIC bus, which is not depicted, coupling the first processor 120 and the second processor 125 together.
Device 105 may also include memory 155. Memory may be any style of storage, wherein data may be stored. For example, memory 155 may be registers to store information. Memory 155 may also be another level of cache 145. Memory 155 may also be a form of system memory placed on device 105.
Memory 155 has at least a first memory location 160 and a second memory location 165. First memory location 160 may contain default system management handler code. First memory location 160 may also be 1 k aligned. Second memory location 165 may be another non-1 k aligned address. First memory location 160 and second memory location 165 may also be base addresses for a first processor 120 and second processor 125 respectively. Second memory location 165 may also be used as temporary storage space, when relocating first processor 120's base address. The first and second memory locations will be discussed in more detail in reference to the methods described in
FIG. 3's illustrative system will be used to describe the methods depicted in FIG'S. 4-9. Although
In block 405, a first system management interrupt (SMI) is received. Often a SMI is generated to request a service from a processor. Once an SMI is received, a processor enters system management mode (SMM) to service the request by running SMI handler code and routines in conventional memory, unless the processor is inactive and not responding to interrupts.
As an illustrative example, the first SMI in block 405 may be generated by a controller hub, such as controller hub 345 depicted in
The first SMI in block 405 may be a service request to initialize SMM, to allocate address space for system management, and/or to relocate a processors base address (SMBase). The SMBase may be the address where the system management portion of memory begins. The SMBase may also be the address where the system management portion of memory is referenced from. For example, the SMBase may be a value of 0x30000. The SMI handler for that portion of memory might be referenced to the SMBase by an offset. For example, the SMI handler may be offset from the SMBase by 0x8000 (SMBase+0x8000), which would put the SMI handler at 0x38000 in the example.
When the SMI is generated in a multiprocessor system both a first processor and a second processor should receive/latch the SMI. However, the second processor may not enter SMM and handle the SMI at this time, since it may be in an inactive state (not responding to interrupts). In contrast, in block 410, the first processor may be active and may handle the first SMI received in block 405. When the first SMI is received by the first processor, the first processor may enter system management mode (SMM) to service/handle the SMI.
As shown in
As depicted in
Turning back to
In the next block, block 425, the first SMI received in block 405, is handled by the second processor. Although, the second processor may have been inactive when first SMI in block 405 was received, and therefore, unable to service the SMI at that time; the second processor may still have latched the SMI when it was in an inactive state. Once awake, the second processor may handle the first SMI that was previously latched.
In block 610, a first processor executes SMI code (an SMI handler) to handle the SMI for the first processor. Handling an SMI may include executing SMI code to determine if the current processor's save-state area being examined generated the SMI. Handling the SMI may also include servicing the SMI request.
As stated above in reference to
As an illustrative example, the target SMBase may be set by default to reference a first SMBase address, which is the starting address of a first processor's system management area. Therefore, when an SMI is received and the SMI handler code is executed, the SMI handler code is able to access the first processor system management area, which may include the first processor's save-state area, by referencing off the target SMBase.
After executing the SMI code in block 610 to handle the SMI for the first processor, the same SMI code/handler may be executed to handle the SMI for second processor, as shown in block 615. In
Continuing the illustrative example from above, after executing the SMI handler code with the target SMBase targeting the first SMBase, the target SMBase may be changed to target the second SMBase address. The second SMBase address may be the starting address of the second processor's system management area (memory space). Therefore, when the SMI handler is executed using the second processor's SMBase as the target SMBase, as in block 710, the same SMI code/handler is able to handle the SMI for the second processor by referencing off the second processor's SMBase address.
However, if the SMI was software generated then the second processor should handle the SMI as well. In block 820, the second processor may then execute the same SMI code that first processor executed in block 805.
An illustrative example of executing the same SMI code is depicted in
It is readily apparent that any combination of the first and second processor may execute the SMI code. For example, the first processor may execute the SMI code for the first processor. Then, after the target SMBase is changed to the second processor's SMBase, the first processor may execute the SMI code again to handle the SMI for the second processor. As another example, the second processor may execute the SMI code both times. As yet another example, the first processor may execute the SMI code the first time the SMI code is executed to handle the SMI for the first processor, and the second processor may execute the SMI code the second time to handle the SMI for the second processor.
Therefore, unlike current systems these optimizations may use only one SMI to be generated to wake and begin execution of a second processor. Furthermore, unlike traditional methods, which start each processor at a different default memory address, memory may be saved by sending a wake-up signal that starts the second processor at first memory address, which may be the location of a default SMI handler. Moreover, by patching the instruction pointer when the second processor handles the first SMI, the second processor may resume at a second memory address, which may be non-aligned. Allowing second processor to resume at second memory address saves the allocation of a separate aligned memory space for each processor.
In addition, handling an SMI may be done with a unified handler, by executing the same handler code with a first processor and then with a second processor. By checking to see if the SMI being handled was software generated and exiting SMM if the SMI was not software generated, one may save a significant amount of execution time. Furthermore, this implementation allows for easier platform development since all changes required for the software SMI handler may easily be contained in wrapper code without requiring modification to the software SMI handler routines.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5530891 *||May 31, 1994||Jun 25, 1996||Advanced Micro Devices||System management interrupt mechanism within a symmetrical multiprocessing system|
|US5613071 *||Jul 14, 1995||Mar 18, 1997||Intel Corporation||Method and apparatus for providing remote memory access in a distributed memory multiprocessor system|
|US5761516||May 3, 1996||Jun 2, 1998||Lsi Logic Corporation||Single chip multiprocessor architecture with internal task switching synchronization bus|
|US5768585 *||Nov 21, 1995||Jun 16, 1998||Intel Corporation||System and method for synchronizing multiple processors during power-on self testing|
|US5938765 *||Aug 29, 1997||Aug 17, 1999||Sequent Computer Systems, Inc.||System and method for initializing a multinode multiprocessor computer system|
|US5978903 *||Aug 19, 1997||Nov 2, 1999||Advanced Micro Devices, Inc.||Apparatus and method for automatically accessing a dynamic RAM for system management interrupt handling|
|US5996058||Aug 19, 1996||Nov 30, 1999||Samsung Electronics Company, Ltd.||System and method for handling software interrupts with argument passing|
|US6065121 *||Mar 31, 1998||May 16, 2000||Compaq Computer Corporation||Control of computer system wake/sleep transitions|
|US6158000 *||Sep 18, 1998||Dec 5, 2000||Compaq Computer Corporation||Shared memory initialization method for system having multiple processor capability|
|US6192442 *||Apr 29, 1998||Feb 20, 2001||Intel Corporation||Interrupt controller|
|US6237120 *||Jan 4, 1995||May 22, 2001||Sony Corporation||Program patching of a ROM|
|US6272618 *||Mar 25, 1999||Aug 7, 2001||Dell Usa, L.P.||System and method for handling interrupts in a multi-processor computer|
|US6282601 *||Mar 31, 1999||Aug 28, 2001||International Business Machines Corporation||Multiprocessor data processing system and method of interrupt handling that facilitate identification of a processor requesting a system management interrupt|
|US6308278 *||Dec 30, 1997||Oct 23, 2001||Intel Corporation||Supplying standby voltage to memory and wakeup circuitry to wake a computer from a low power mode|
|US6374338 *||Jun 25, 1999||Apr 16, 2002||International Business Machines Corporation||Method for performing configuration tasks prior to and including memory configuration within a processor-based system|
|US6446213 *||Aug 31, 1998||Sep 3, 2002||Kabushiki Kaisha Toshiba||Software-based sleep control of operating system directed power management system with minimum advanced configuration power interface (ACPI)-implementing hardware|
|US6611911 *||Dec 30, 1999||Aug 26, 2003||Intel Corporation||Bootstrap processor election mechanism on multiple cluster bus system|
|US6615329 *||Jul 11, 2001||Sep 2, 2003||Intel Corporation||Memory access control system, apparatus, and method|
|US6711642 *||Jun 11, 2001||Mar 23, 2004||Via Technologies, Inc.||Method and chipset for system management mode interrupt of multi-processor supporting system|
|US6775734 *||Oct 9, 2001||Aug 10, 2004||Via Technologies, Inc.||Memory access using system management interrupt and associated computer system|
|US6782472 *||Mar 12, 2003||Aug 24, 2004||Intel Corporation||Method of initializing a memory controller by executing software in a second memory to wake up a system|
|US6792480 *||Apr 17, 2002||Sep 14, 2004||Hewlett-Packard Development Company, L.P.||Status display being visible in a closed position and displaying a track number during play mode comprising a reduced power of a system|
|US6836849 *||Apr 5, 2001||Dec 28, 2004||International Business Machines Corporation||Method and apparatus for controlling power and performance in a multiprocessing system according to customer level operational requirements|
|US6842857 *||Apr 12, 2001||Jan 11, 2005||International Business Machines Corporation||Method and apparatus to concurrently boot multiple processors in a non-uniform-memory-access machine|
|US6848046 *||May 11, 2001||Jan 25, 2005||Intel Corporation||SMM loader and execution mechanism for component software for multiple architectures|
|US6925556 *||Feb 14, 2001||Aug 2, 2005||Intel Corporation||Method and system to determine the bootstrap processor from a plurality of operable processors|
|US6968410 *||Feb 28, 2001||Nov 22, 2005||Intel Corporation||Multi-threaded processing of system management interrupts|
|US6968412 *||Dec 30, 1999||Nov 22, 2005||Intel Corporation||Method and apparatus for interrupt controller data re-direction|
|US7043729 *||Aug 8, 2002||May 9, 2006||Phoenix Technologies Ltd.||Reducing interrupt latency while polling|
|US7146515 *||Jun 20, 2002||Dec 5, 2006||International Business Machines Corporation||System and method for selectively executing a reboot request after a reset to power on state for a particular partition in a logically partitioned system|
|US7152169 *||Nov 29, 2002||Dec 19, 2006||Intel Corporation||Method for providing power management on multi-threaded processor by using SMM mode to place a physical processor into lower power state|
|US20020099893 *||Jan 24, 2001||Jul 25, 2002||Nguyen Tuyet-Huong Thi||System and method for the handling of system management interrupts in a multiprocessor computer system|
|US20030009654 *||Jun 29, 2001||Jan 9, 2003||Nalawadi Rajeev K.||Computer system having a single processor equipped to serve as multiple logical processors for pre-boot software to execute pre-boot tasks in parallel|
|US20030093579 *||Nov 15, 2001||May 15, 2003||Zimmer Vincent J.||Method and system for concurrent handler execution in an SMI and PMI-based dispatch-execution framework|
|US20030224768 *||May 23, 2003||Dec 4, 2003||Sendo International Limited||Processor Re-Start Control|
|US20040034854 *||Aug 13, 2002||Feb 19, 2004||Cottrell Andrew P.||Method for meeting SMI duration limits by time slicing SMI handlers|
|EP0720094A2||Dec 29, 1995||Jul 3, 1996||Compaq Computer Corporation||Circuit for reassigning the power-on processor in a multiprocessing system|
|EP0817038A2||Jun 23, 1997||Jan 7, 1998||Sun Microsystems, Inc.||Node to node interrupt mechanism in a multi-processor system|
|EP0818736A2||Jul 7, 1997||Jan 14, 1998||Digital Equipment Corporation||System for assigning boot strap processor in symmetric multiprocessor computer with watchdog reset|
|GB2382180A||Title not available|
|1||Kobayashi, et al. U.S. Appl. No. 10/307,146, Filed Nov. 30, 2002, "Apparatus and Method for Multi-Threaded Processors Performance Control," 36 pages.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7797473 *||Sep 14, 2010||Dell Products, Lp||System for executing system management interrupts and methods thereof|
|US7802042||Dec 28, 2007||Sep 21, 2010||Intel Corporation||Method and system for handling a management interrupt event in a multi-processor computing device|
|US8001308||Sep 17, 2010||Aug 16, 2011||Intel Corporation||Method and system for handling a management interrupt event in a multi-processor computing device|
|US8024504||Sep 20, 2011||Microsoft Corporation||Processor interrupt determination|
|US8214573||Jul 3, 2012||Intel Corporation||Method and system for handling a management interrupt event in a multi-processor computing device|
|US8341438 *||Dec 25, 2012||Panasonic Corporation||Information processing device for assigning interrupts to a first CPU or a second CPU based on a sleeping state|
|US20090172228 *||Dec 28, 2007||Jul 2, 2009||Zimmer Vincent J||Method and system for handling a management interrupt event in a multi-processor computing device|
|US20090172232 *||Dec 28, 2007||Jul 2, 2009||Zimmer Vincent J||Method and system for handling a management interrupt event|
|US20090307403 *||Dec 10, 2009||Dell Products, Lp||System for executing system management interrupts and methods thereof|
|US20090327555 *||Jun 26, 2008||Dec 31, 2009||Microsoft Corporation||Processor Interrupt Determination|
|US20090327556 *||Jun 27, 2008||Dec 31, 2009||Microsoft Corporation||Processor Interrupt Selection|
|US20100185886 *||Mar 18, 2010||Jul 22, 2010||Shuichi Mitarai||Information processing device|
|US20110004715 *||Jan 6, 2011||Zimmer Vincent J||Method and system for handling a management interrupt event in a multi-processor computing device|
|U.S. Classification||710/260, 710/269|
|International Classification||G06F13/24, G06F9/445, G06F9/48|
|Cooperative Classification||G06F9/4812, G06F9/4401|
|European Classification||G06F9/44A, G06F9/48C2|
|Oct 6, 2003||AS||Assignment|
Owner name: INTEL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:COOPER, BARNES;KOBAYASHI, GRANT H.;REEL/FRAME:014605/0142;SIGNING DATES FROM 20030915 TO 20030924
|Oct 1, 2012||REMI||Maintenance fee reminder mailed|
|Oct 24, 2012||FPAY||Fee payment|
Year of fee payment: 4
|Oct 24, 2012||SULP||Surcharge for late payment|