Heuristic based affinity dispatching for shared processor partition dispatching

A mechanism is provided for determining whether to use cache affinity as a criterion for software thread dispatching in a shared processor logical partitioning data processing system. The server firmware may store data about when and/or how often logical processors are dispatched. Given these data, the operating system may collect metrics. Using the logical processor metrics, the operating system may determine whether cache affinity is likely to provide a significant performance benefit relative to the cost of dispatching a particular logical processor to the operating system.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to co-pending U.S. patent application Ser. No. 11/419,047, entitled “METHOD, APPARATUS, AND PROGRAM PRODUCT FOR OPTIMIZATION OF THREAD WAKE UP FOR SHARED PROCESSOR PARTITIONS,” filed on an even date herewith.

BACKGROUND

1. Technical Field

The present application relates generally to an improved data processing system and method. More specifically, the present application is directed to mechanisms for heuristic based affinity dispatching for shared processor partition dispatching.

2. Description of Related Art

Logical partitioning (LPAR) is the ability to make a server run as if it were two or more independent servers. When one logically partitions a server, one divides the resources on the server into subsets called logical partitions. Processors, memory, and input/output devices are examples of resources that can be assigned to logical partitions. A logical partition runs as an independent logical server with the processor, memory, and I/O resources allocated to it. Examples of the kinds of software that can be installed and run on logical partitions include the AIX®, i5/OS™, and Linux® operating systems and Virtual I/O Server software. “AIX” and “i5/OS” are trademarks of International Business Machines Corporation in the United States, other countries, or both. “LINUX” is a trademark of Linus Torvalds in the United States, other countries, or both.

The Hardware Management Console (HMC) is an example of a hardware appliance that connects to the server firmware. The HMC may be used to specify to the server firmware how to allocate resources among the logical partitions on the managed system. The HMC may also be used to start and stop the logical partitions, update server firmware code, manage Capacity on Demand, and transmit service information to service and support if there are any hardware problems with the managed system. The server firmware is code that is stored in system flash memory on the server. The server firmware directly controls resource allocations on the server and communications between logical partitions on the server.

Although each logical partition acts as an independent server, the logical partitions on a physical server can share some kinds of resources with each other. The ability to share resources among many logical partitions allows increased resource utilization on the server by shifting the server resources to where they are needed.

A processor is a device that processes programmed instructions. The more processors assigned to a logical partition, the greater the number of concurrent operations the logical partition can run at any given time. Dedicated processors are whole processors that are assigned to a single partition. Shared processors are physical processors whose processing capacity is shared among multiple logical partitions.

The ability to divide physical processors and share them among multiple logical partitions is known as Micro-Partitioning™ or shared processor logical partitioning (SPLPAR). Micro-Partitioning™ (or shared processing) allows logical partitions to share the processors in the shared processor pool. “MICRO-PARTITIONING” is a trademark of International Business Machines Corporation in the United States, other countries, or both. The shared processor pool includes all processors on the server that are not dedicated to specific logical partitions. Each logical partition that uses the shared processor pool is assigned a specific amount of processor power from the shared processor pool. If the logical partition needs more processor power than its assigned amount, the logical partition may (capped/uncapped defines this) use the unused processor power in the shared processor pool. The amount of processor power that an uncapped logical partition can use is limited only by the virtual processor settings of the logical partition and the amount of unused processor power available in the shared processor pool.

Virtualization is the pooling of data processing resources in a way that shields the physical nature and boundaries of those resources from users. Virtualization of processors through shared processor partitioning involves an additional layer of software, or firmware, between the operating system(s) and the hardware. Additionally, optimizations to the operating system(s) are usually required for best performance and responsiveness.

In the operating system, when a software thread is waiting on some event (e.g., a lock wait or waiting on data to reach a socket) and the event occurs, the operating system makes the software thread runnable and determines on which logical processor to run the thread. Work to be done within an operating system is broken into processes and further into threads. Generally speaking, a process is usually, but not always, analogous to an application program. The threads of a process share the same virtual address space, but run semi-independently. Thus, while one thread is waiting for a file to be read in from disk, another thread can be performing calculations, for example. Typically, the operating system attempts to run the thread on the same logical processor to maintain cache affinity.

One very key factor in the overhead introduced with shared processor partitioning is cache thrashing. Effectively, each operating system has a set of unique storage that it typically touches when running work. In a system without shared processor logical partitioning, the hardware caches of the system tend to do a good job of containing a set of unique storage, or footprint. However, with shared processor logical partitioning, the firmware dispatches and undispatches processors to operating systems over time, which tends to reduce the effectiveness of the hardware caches.

SUMMARY

The exemplary embodiments recognize the disadvantages of the prior art and provide a mechanism for determining whether to use cache affinity as a criterion for software thread dispatching in a shared processor logical partitioning data processing system. The server firmware may store data about when and/or how often logical processors are dispatched. Given these data, the operating system may collect metrics. Using the logical processor metrics, the operating system may determine whether cache affinity is likely to provide a significant performance benefit relative to the cost of dispatching a particular logical processor to the operating system.

In one illustrative embodiment, a method for determining whether to use cache affinity as a criterion for software thread dispatching in a shared processor logical partitioning data processing system is provided. Responsive to a software thread being made ready to run, the method determines whether cache affinity is not likely to provide a performance benefit. Responsive to a determination that cache affinity is not likely to provide a performance benefit, the method selects a logical processor based on other criteria. The method queues the software thread to run on the selected logical processor. Responsive to a determination that cache affinity is likely to provide a performance benefit, the method identifies a logical processor on which the software thread was last dispatched and queues the software thread to run on the logical processor on which the software thread was last dispatched. Determining whether cache affinity is not likely to provide a performance benefit comprises determining whether the software thread has been undispatched for a predetermined period of time, determining whether a logical processor on which the software thread was last dispatched has not been undispatched since the last time the software thread was dispatched, determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched since the last time the software thread was undispatched, determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched a predetermined number of times since the last time the software thread was undispatched, and determining whether a number of non-affinity dispatches of a logical processor on which the software thread was last dispatched is non-zero.

In one exemplary embodiment, responsive to a determination that cache affinity is likely to provide a performance benefit, the method identifies a logical processor on which the software thread was last dispatched and queues the software thread to run on the logical processor on which the software thread was last dispatched.

In another exemplary embodiment, determining whether cache affinity is not likely to provide a performance benefit comprises determining whether the software thread has been undispatched for a predetermined period of time.

In yet another exemplary embodiment, determining whether cache affinity is not likely to provide a performance benefit comprises determining whether a logical processor on which the software thread was last dispatched has not been undispatched since the last time the software thread was dispatched.

In a further exemplary embodiment, determining whether cache affinity is not likely to provide a performance benefit comprises determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched since the last time the software thread was undispatched.

In yet another exemplary embodiment, determining whether cache affinity is not likely to provide a performance benefit comprises determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched a predetermined number of times since the last time the software thread was undispatched.

In another exemplary embodiment, determining whether cache affinity is not likely to provide a performance benefit comprises determining whether a number of non-affinity dispatches of a logical processor on which the software thread was last dispatched is non-zero.

In another illustrative embodiment, an apparatus for determining whether to use cache affinity as a criterion for software thread dispatching in a shared processor logical partitioning data processing system is provided. The apparatus may comprise an operating system running in a shared processor logical partition and a server firmware that dispatches resources to the operating system. Responsive to a software thread being made ready to run, the operating system may determine whether cache affinity is not likely to provide a performance benefit. Responsive to a determination that cache affinity is not likely to provide a performance benefit, the operating system may select a logical processor based on other criteria. The operating system may queue the software thread to run on the selected logical processor. Responsive to a determination that cache affinity is likely to provide a performance benefit, the operating system identifies a logical processor on which the software thread was last dispatched and queues the software thread to run on the logical processor on which the software thread was last dispatched. Determining whether cache affinity is not likely to provide aperformance benefit comprises determining whether the software thread has been undispatched for a predetermined period of time, determining whether a logical processor on which the software thread was last dispatched has not been undispatched since the last time the software thread was dispatched, determining whethera logical processor on which the software thread was last dispatched has been dispatched and undispatched since the last time the software thread was undispatched, determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched a predetermined number of times since the last time the software thread was undispatched, and determining whether a number of non-affinity dispatches of a logical processor on which the software thread was last dispatched is non-zero.

In other exemplary embodiments, the apparatus performs various ones of the operations outlined above with regard to the method in the illustrative embodiments.

In another illustrative embodiment, a computer program product comprising a computer useable medium having a computer readable program is provided. The computer readable program, when executed on a computing device, may cause the computing device to responsive to a software thread being made ready to run, determine whether cache affinity is not likely to provide a performance benefit. Further, the computer readable program may cause the computing device to select a logical processor based on other criteria responsive to a determination that cache affinity is not likely to provide a performance benefit. Still further, the computer readable program may cause the computing device to queue the software thread to run on the selected logical processor. Responsive to a determination that cache affinity is likely to provide a performance benefit, the computer readable program may cause the computing device to identify a logical processor on which the software thread was last dispatched and queue the software thread to run on the logical processor on which the software thread was last dispatched. Determining whether cache affinity is not likely to provide a performance benefit comprises determining whether the software thread has been undispatched for a predetermined period of time, determining whether a logical processor on which the software thread was last dispatched has not been un dispatched since the last time the software thread was dispatched, determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched since the last time the software thread was undispatched, determining whether a logical processor on which the software thread was last dispatched has been dispatched and undispatched a predetermined number of times since the last time the software thread was undispatched, and determining whether a number of non-affinity dispatches of a logical processor on which the software thread was last dispatched is non-zero.

In other exemplary embodiments, the computer readable program may cause the computing device to perform various ones of the operations outlined above with regard to the method in the illustrative embodiments.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The illustrative embodiments described herein provide mechanisms for heuristic based affinity dispatching for shared processor partition dispatching. As such, the mechanisms of the illustrative embodiments are especially well suited for implementation in a logically partitioned data processing system. The followingFIGS. 1 and 2are provided as examples of a logically partitioned data processing system in which exemplary aspects of the illustrative embodiments may be implemented. It should be noted that the example computing environments illustrated inFIGS. 1 and 2are not intended to state or imply any limitation as to the particular types of computing environments in which the exemplary aspects of the illustrative embodiments may be implemented. Rather, many modifications to the depicted computing environments may be made without departing from the spirit and scope of the present invention.

With reference now to the figures, and in particular with reference toFIG. 1, a block diagram of a data processing system in which exemplary aspects of the illustrative embodiments may be implemented is depicted. Data processing system100may be a symmetric multiprocessor (SMP) system including a plurality of processors101,102,103, and104connected to system bus106. For example, data processing system100may be an IBM eServer™ data processing system, a product of International Business Machines Corporation in Armonk, N.Y., implemented as a server within a network. “eServer” is a trademark of International Business Machines Corporation in the United States, other countries, or both. Alternatively, a single processor system may be employed. Also connected to system bus106is memory controller/cache108, which provides an interface to a plurality of local memories160-163. I/O bus bridge110is connected to system bus106and provides an interface to I/O bus112. Memory controller/cache108and I/O bus bridge110may be integrated as depicted.

Data processing system100is a logical partitioned (LPAR) data processing system. Thus, data processing system100may have multiple heterogeneous operating systems (or multiple instances of a single operating system) running simultaneously. Each of these multiple operating systems may have any number of software programs executing within it. Data processing system100is logically partitioned such that different resources, such as processors101-104, PCI I/O adapters120-121,128-129, and136, graphics adapter148, and hard disk adapter149may be assigned to different logical partitions. In this case, graphics adapter148provides a connection for a display device (not shown), while hard disk adapter149provides a connection to control hard disk150.

Thus, for example, suppose data processing system100is divided into three logical partitions, P1, P2, and P3. Each of PCI I/O adapters120-121,128-129,136, graphics adapter148, hard disk adapter149, each of host processors101-104, and memory from local memories160-163, or portions thereof, is assigned to one of the three partitions. In these examples, memories160-163may take the form of dual in-line memory modules (DIMMs). DIMMs are not normally assigned on a per DIMM basis to partitions. Instead, a partition will get a portion of the overall memory seen by the platform. For example, processor101, some portion of memory from local memories160-163, and I/O adapters120,128, and129may be assigned to logical partition P1; processors102-103, some portion of memory from local memories160-163, and PCI I/O adapters121and136may be assigned to partition P2; and processor104, some portion of memory from local memories160-163, graphics adapter148and hard disk adapter149may be assigned to logical partition P3. Although not depicted inFIG. 1, portions of remote memories (not shown) may also be assigned to logical partitions, such as P1or P2in the illustrative example.

Each operating system executing within data processing system100is assigned to a different logical partition. Thus, each operating system executing within data processing system100may access only those I/O units that are within its logical partition. For example, one instance of the Advanced Interactive Executive (AIX®) operating system may be executing within partition P1, a second instance (image) of the AIX® operating system may be executing within partition P2, and a Windows® XP operating system may be operating within logical partition P3. Windows® XP is a product and trademark of Microsoft Corporation of Redmond, Wash. “AIX” is a registered trademark of International Business Machines Corporation in the United States, other countries, or both. “WINDOWS” is a registered trademark of Microsoft Corporation in the United States, other countries, or both.

Peripheral component interconnect (PCI) host bridge114connected to I/O bus112provides an interface to PCI local bus115. A number of PCI input/output adapters120-121may be connected to PCI bus115through PCI-to-PCI bridge116, PCI bus118, PCI bus119, I/O slot170, and I/O slot171. PCI-to-PCI bridge116provides an interface to PCI bus118and PCI bus119. PCI I/O adapters120and121are placed into I/O slots170and171, respectively. Typical PCI bus implementations will support between four and eight I/O adapters (i.e. expansion slots for add-in connectors). Each PCI I/O adapter120-121provides an interface between data processing system100and input/output devices such as, for example, other network computers, which are clients to data processing system100.

An additional PCI host bridge122provides an interface for an additional PCI bus123. PCI bus123is connected to a plurality of PCI I/O adapters128-129. PCI I/O adapters128-129may be connected to PCI bus123through PCI-to-PCI bridge124, PCI bus126, PCI bus127, I/O slot172, and I/O slot173. PCI-to-PCI bridge124provides an interface to PCI bus126and PCI bus127. PCI I/O adapters128and129are placed into I/O slots172and173, respectively. Additional I/O devices, such as, for example, modems or network adapters may be supported through each of PCI I/O adapters128-129. In this manner, data processing system100allows connections to multiple network computers.

A memory mapped graphics adapter148inserted into I/O slot174may be connected to I/O bus112through PCI bus144, PCI-to-PCI bridge142, PCI bus141and PCI host bridge140. Hard disk adapter149may be placed into I/O slot175, which is connected to PCI bus145. In turn, this bus is connected to PCI-to-PCI bridge142, which is connected to PCI host bridge140by PCI bus141.

A PCI host bridge130provides an interface for a PCI bus131to connect to I/O bus112. PCI I/O adapter136is connected to I/O slot176, which is connected to PCI-to-PCI bridge132by PCI bus133. PCI-to-PCI bridge132is connected to PCI bus131. This PCI bus also connects PCI host bridge130to the service processor mailbox interface and ISA bus access pass-through logic194and PCI-to-PCI bridge132.

Service processor mailbox interface and ISA bus access pass-through logic194forwards PCI accesses destined to the PCI/ISA bridge193. NVRAM storage192is connected to the ISA bus196. Service processor135is coupled to service processor mailbox interface and ISA bus access pass-through logic194through its local PCI bus195. Service processor135is also connected to processors101-104via a plurality of JTAG/I2C busses134. JTAG/I2C busses134are a combination of JTAG/scan busses (see IEEE 1149.1) and Phillips I2C busses. However, alternatively, JTAG/I2C busses134may be replaced by only Phillips I2C busses or only JTAG/scan busses. All SP-ATTN signals of the host processors101,102,103, and104are connected together to an interrupt input signal of the service processor. The service processor135has its own local memory191, and has access to the hardware OP-panel190.

When data processing system100is initially powered up, service processor135uses the JTAG/I2C busses134to interrogate the system (host) processors101-104, memory controller/cache108, and I/O bridge110. At completion of this step, service processor135has an inventory and topology understanding of data processing system100. Service processor135also executes Built-In-Self-Tests (BISTs), Basic Assurance Tests (BATs), and memory tests on all elements found by interrogating the host processors101-104, memory controller/cache108, and I/O bridge110. Any error information for failures detected during the BISTs, BATs, and memory tests are gathered and reported by service processor135.

A meaningful/valid configuration of system resources is still possible after taking out the elements found to be faulty during the BISTs, BATs, and memory tests. Then data processing system100is allowed to proceed to load executable code into local (host) memories160-163. Service processor135then releases host processors101-104for execution of the code loaded into local memory160-163. While host processors101-104are executing code from respective operating systems within data processing system100, service processor135enters a mode of monitoring and reporting errors. The type of items monitored by service processor135include, for example, the cooling fan speed and operation, thermal sensors, power supply regulators, and recoverable and non-recoverable errors reported by processors101-104, local memories160-163, and I/O bridge110.

Service processor135is responsible for saving and reporting error information related to all the monitored items in data processing system100. Service processor135also takes action based on the type of errors and defined thresholds. For example, service processor135may take note of excessive recoverable errors on a processor's cache memory and decide that this is predictive of a hard failure. Based on this determination, service processor135may mark that resource for deconfiguration during the current running session and future Initial Program Loads (IPLs). IPLs are also sometimes referred to as a “boot” or “bootstrap.”

Data processing system100may be implemented using various commercially available computer systems. For example, data processing system100may be implemented using IBM eServer™ i5 or eServer™ p5 server models available from International Business Machines Corporation. Such a system may support logical partitioning using an AIX® operating system or an i5/OS™ operating system which are also available from International Business Machines Corporation.

With reference now toFIG. 2, a block diagram of an exemplary logical partitioned platform is depicted in which exemplary aspects of the illustrative embodiments may be implemented. The hardware in logical partitioned platform200may be implemented as, for example, data processing system100inFIG. 1. Logical partitioned platform200includes partitioned hardware230, operating systems202,204,206,208, and firmware210. Operating systems202,204,206, and208may be multiple copies of a single operating system or multiple heterogeneous operating systems simultaneously running on platform200. These operating systems may be implemented using the AIX® operating system, the i5/OS™ operating system or the Linux™ operating system, for example, which are designed to interface with server firmware. Operating systems202,204,206, and208are located in partitions203,205,207, and209.

Additionally, these partitions also include firmware loaders211,213,215, and217. Firmware loaders211,213,215, and217may be implemented using IEEE-1275 Standard Open Firmware and runtime abstraction software (RTAS), which is available from International Business Machines Corporation. When partitions203,205,207, and209are instantiated, a copy of the open firmware is loaded into each partition by the firmware's partition manager. The processors associated or assigned to the partitions are then dispatched to the partition's memory to execute the partition firmware.

Firmware210performs a number of functions and services for partitions203,205,207, and209to create and enforce the partitioning of logical partitioned platform200. Firmware210is a firmware implemented virtual machine identical to the underlying hardware. Hypervisor software is an example of server firmware available from International Business Machines Corporation. Firmware is “software” stored in a memory chip that holds its content without electrical power, such as, for example, read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), and nonvolatile random access memory (nonvolatile RAM). Thus, firmware210allows the simultaneous execution of independent operating system images202,204,206, and208by virtualizing all hardware resources of logical partitioned platform200. Virtualization is the pooling of data processing resources in a way that shields the physical nature and boundaries of those resources from operating systems and users.

Operations of the different partitions may be controlled through a hardware management console, such as hardware management console280. Hardware management console280is a separate data processing system from which a system administrator may perform various functions including reallocation of resources to different partitions. Alternatively, a Virtual Partition Manager is a feature of the i5/OS™ V5R3 operating system that allows one to create and manage one operating system logical partitions by initiating a console session using service tools.

Partitioned hardware230includes a plurality of processors232-238, a plurality of system memory units240-246, a plurality of input/output (I/O) adapters248-262, and a storage unit270. Partitioned hardware230also includes service processor290, which may be used to provide various services, such as processing of errors in the partitions. Each of the processors232-238, memory units240-246, NVRAM storage298, and I/O adapters248-262may be assigned to one of multiple partitions within logical partitioned platform200, each of which corresponds to one of operating systems202,204,206, and208.

Processors232-238may be dispatched to partitions203,205,207,209as dedicated processors or shared processors. Dedicated processors are whole processors that are assigned to a single partition. Shared processors are physical processors whose processing capacity is shared among multiple logical partitions. The ability to divide physical processors and share them among multiple logical partitions is known as Micro-Partitioning™ or shared processor logical partitioning (SPLPAR). The shared processor pool includes all processors in partitioned hardware230that are not dedicated to specific logical partitions. Each logical partition that uses the shared processor pool is assigned a specific amount of processor power from the shared processor pool.

FIG. 3illustrates an example logically partitioned data processing system with dedicated processors and shared processors in accordance with an illustrative embodiment. Partition310runs operating system312; partition320runs operating system322; partition330runs operating system332; and, partition340runs operating system342. Server firmware350may dispatch processor334to partition330and processors344and346to partition340as dedicated processors. Server firmware350may dispatch processor314to partitions310and320from a shared processor pool including all processors not assigned as dedicated processors (i.e. all processors except processors334,344,346).

Because operating systems332and342are assigned dedicated processors, these operating systems may make safe assumptions about cache affinity when dispatching threads to their logical processors. In the depicted example, a logical processor may be a whole physical processor or a portion of a physical processor. For example, a logical processor may be a given core of a multiple core processor or a given hardware thread in a multi-threading processor. However, the manner in which physical processors are divided into logical processors is not a focus of this disclosure.

For simplicity, consider a single operating system function that is used to place a thread, which was waiting on an event and is now ready to run, on a logical processor. For operating systems running with dedicated processor resources, the approach is to identify a logical processor that is idle. Additionally, the operating system biases the placement to try to place the thread onto the logical processor (or virtual processor) on which the thread last ran or processors associated with caches where the thread last ran. This preserves cache affinity in dedicated processor partitions.

On the other hand, operating systems312and322are assigned logical processors for their tasks from a shared processor pool. In the depicted example, a logical processor may be a portion of a physical processor. For example, a logical processor may be a given core of a multiple core processor or a given hardware thread in a multi-threading processor. As another example, a logical processor may be a time-sliced portion of a physical processor or processing core. For instance, processor314may be a single physical processor that is time sliced to form virtual processors for partitions310and320. In this instance, each partition may receive 50% of processor314time-wise. That is, partition310may receive a 10 ms time slice and then partition320may receive a 10 ms time slice and so on. However, the manner in which physical processors are divided into logical processors is not a focus of this disclosure.

When running in a shared processor logical partitioning environment, the value of cache affinity is difficult to predict. This is due to the fact that the server firmware dispatches virtual processors on the physical hardware. In fact, for transactional workloads using databases or application servers, the server firmware dispatchers' effective affinity when placing the virtual processors may be very poor. This is a consequence of the fact that it is difficult to fully utilize the system in transactional environments, since the response time for transactions rises with processor utilization. Therefore, systems tend to dispatch virtual processors rapidly and for short time duration. At high system utilization the server firmware usually has a limited set of virtual processors to dispatch at any given time, which frequently results in poor affinity.

Consequently, if an operating system queues a software thread to be run on a particular logical processor, that logical processor may be currently undispatched as a result of actions by the server firmware. The overhead of the context switch for undispatching the logical processor from the other logical partition and then dispatching the logical processor may far outweigh the benefit of cache affinity, if any. Even if the logical processor is not dispatched to another physical partition, or even if the logical processor is currently dispatched to the instant operating system in question, the possibility exists that the logical processor had been dispatched to other logical partitions in the meantime, in which case there is likely no cache state left for the software thread being dispatched.

In accordance with an exemplary embodiment, the operating system determines if cache affinity is likely to be beneficial in a shared processor environment, rather than always assuming that cache affinity should be an important criterion in dispatching software threads onto logical processors. If cache affinity is most likely lost, the operating system may make dispatching decisions based on other criteria.

Affinity is relative to cache domain. In general, the cache domain is defined according to size or latency of cache. Multiple logical processors may be in the same cache domain if they share a common cache.FIG. 4illustrates an example multiple core processor to which exemplary aspects of the illustrative embodiments may apply. Processor400includes core410and core420. Core410includes processing unit412and level-one (L1) cache414. Similarly, core420includes processing unit422and L1 cache424. In the depicted example, core410and core420share level-two (L2) cache430and level-three (L3) cache440.

In one exemplary implementation, the cache domain may be defined by L1 cache, in which case core410and core420will lie in different cache domains. However, in an alternative implementation, the cache domain may be defined consistent with L3 cache, which may be the largest size cache. In this case, core410and core420will lie in the same cache domain. Thus, in this exemplary implementation a logical processor associated with core410may be within the same cache domain as a logical processor associated with core420.

Consider an operating system dispatches a given software thread to run on a particular logical processor, and the server firmware dispatches the particular logical processor to run on core410. Then, if the operating system subsequently dispatches the given software thread to run on the particular logical processor and the server firmware dispatches the logical processor to run on core420, the logical processor will remain in the same cache domain if the cache domain is defined at the L2 cache level.

FIG. 5is a block diagram illustrating the collection of processor metrics in a logically partitioned data processing system in accordance with one exemplary embodiment. Operating system510runs in one given partition, and operating system520runs in another partition. Hypervisor560dispatches processing resources to the partitions to support operating systems510and520.

Operating system510registers virtual processor area (VPA)562, and operating system520registers a virtual processor area564. Virtual processor area562, for example, serves as a two-way communications area between operating system510and hypervisor560regarding details of the virtual processor. The virtualization architecture defines a virtual processor area. When a virtual processor is created, its virtual processor area is also created. Hypervisor560provides to each logical processor, via the corresponding virtual processor area, a count of the total logical processor dispatches and the number of affinity logical processor dispatches.

The operating system keeps track of the last logical processor on which a software thread had been dispatched. In accordance with one exemplary embodiment, the operating system may keep all or any subset of the following metrics to use in deciding the value of affinity:1. The time of the last undispatch of a software thread;2. The dispatch count of the logical processor at the time that each software thread was last undispatched (e.g. running count of all dispatches for a virtual processor);3. The dispatch count of the current dispatch of the logical processor;4. The time of dispatch of a logical processor;5. The number of affinity dispatches of a logical processor;6. The physical processor on which the last dispatch of a logical processor occurred;7. The logical processor(s) currently dispatched.

Operating system510keeps track of logical processor metrics512, and operating system520keeps track of logical processor metrics522, which may include all or a subset of the above metrics. Using logical processor metrics512,522, operating systems510,520may apply an algorithm to decide the likelihood that enforcing affinity will have performance benefit versus dispatching to a logical processor based on other criteria.

If a software thread has been undispatched for a long time and the software thread is part of a single threaded process, there is likely no cache state left for that thread, because the cache space was reused by other software threads in execution. The time to replace the cache will be related to the size(s) of the processor caches, the miss rate from the caches, and the time to fetch the new contents of the cache from the various levels of the memory subsystem. The miss rate and effective latency may be observed by the operating system via the hardware performance monitor. Alternatively, a base heuristic time could be used. The operating system may handle special tracking for multi-threaded processes to determine if any threads of a process have been recently dispatched on the logical processor. This time to replace the cache, or the base heuristic time, may be used to derive a threshold.

If the logical processor on which the software thread had last been dispatched has not been undispatched since the last time the software thread was dispatched, it is very possible that some cache state is left for the software thread. In other words, if the logical processor remains dispatched to the same operating system, then it is likely that cache affinity will provide some performance benefit. In this case, affinity should be preserved.

If the target logical processor has been dispatched and undispatched a predetermined number of times since the software thread was undispatched, it is likely that the cache state for the thread is gone and affinity would not provide a performance benefit. In other words, the more times the logical processor is dispatched and undispatched, the more likely it is that the processor has been dispatched to another partition and its cache if filled with data that are not useful to the current software thread. That is, the software thread being dispatched is likely to experience a high number of cache misses.

If the target logical processor has been dispatched and undispatched since the software thread was undispatched and the number of non-affinity dispatches is non-zero, then cache state is likely lost for the thread. A non-affinity dispatch is a documented instance that the logical processor has been dispatched to a physical processor or core in a different cache domain or that the logical processor has been dispatched to a different logical partition.

In various embodiments, the algorithm for determining the value of affinity may include all or a subset of the above criteria. For example, the operating system may determine whether to use affinity as a criterion for dispatching a software thread to a logical processor based only on the amount of time that has elapsed since the last time the software thread was undispatched. In another embodiment, the operating system may use all of the above criteria or other criteria to determine whether the use cache affinity for dispatching the software thread.

If the operating system determines that affinity is not likely to provide a benefit, then selection of a logical processor on which to dispatch a software thread may be based on other criteria. These other criteria may include, for example, whether a logical processor is idle, whether a logical is idle but currently dispatched, best software priority fit, optimum usage of logical processors to improve overall system throughput, or any other standard operating system criteria.

FIG. 6is a flowchart illustrating operation of an operating system for dispatching a software thread in accordance with an exemplary embodiment. It will be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by computer program instructions. These computer program instructions may be provided to a processor or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the processor or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be embodied in a computer-readable memory, storage medium, or transmission medium that can direct a processor or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory, storage medium, or transmission medium produce an article of manufacture including instruction means that implement the functions specified in the flowchart block or blocks.

With particular reference toFIG. 6, operation begins when an operating system is ready to dispatch a software thread to a logical processor. The operating system examines collected logical partition metrics (block602). The operating system identifies the last logical processor on which the software thread was dispatched (block604).

The operating system determines whether the software thread is part of a single threaded process (block606). If the software thread is part of a single threaded process, the operating system determines whether the amount of time the software thread was undispatched is greater than a threshold (block608). The threshold may be based on the amount of time it would take to replace the cache, which may be related to the sizes of the processor caches and the miss rate. If the amount of time the software thread was undispatched is greater than the threshold, the operating system selects a logical processor based on other criteria (block610) and attempts to queue the thread to the selected logical processor (block612). Thereafter, operation ends.

If the software thread is not part of a single threaded process in block606or the amount of time the software thread was undispatched is not greater than the threshold in block608, the operating system determines whether the logical processor has been undispatched since the last time the software thread was dispatched (block614). If the logical processor has not been undispatched, then the operating system attempts to queue the thread to the last logical processor on which the thread was dispatched (block616). Thereafter, operation ends.

If the logical processor has been undispatched since the last time the software thread was undispatched in block614, then the operating system determines whether the logical processor has been dispatched and undispatched since the software thread last undispatched (block618). If the logical processor has not been dispatched and undispatched, then the operating system attempts to queue the thread to the last logical processor on which the thread was dispatched (block616). Thereafter, operation ends.

If the logical processor has been dispatched and undispatched since the last time the software thread was undispatched in block618, the operating system determines whether the number of non-affinity dispatches is non-zero (block620). If the number of non-affinity dispatches is non-zero, the operating system selects a logical processor based on other criteria (block610) and attempts to queue the thread to the selected logical processor (block612). Thereafter, operation ends.

If the number of non-affinity dispatches is zero in block620, the operating system determines whether the number of times the logical processor has been dispatched and undispatched is greater than a predetermined threshold (block622). This threshold may be set by an administrator or developer to ensure optimum performance. If the number of times the logical processor has been dispatched and undispatched is greater than the predetermined threshold, then the operating system selects a logical processor based on other criteria (block610) and attempts to queue the thread to the selected logical processor (block612). Thereafter, operation ends. However, if the number of times the logical processor has been dispatched and undispatched is not greater than the threshold, then the operating system attempts to queue the thread to the last logical processor on which the thread was dispatched (block616). Thereafter, operation ends.

Thus, the exemplary embodiments solve the disadvantages of the prior art by providing a mechanism for determining whether to use cache affinity as a criterion for software thread dispatching in a shared processor logical partitioning data processing system. The server firmware may store data about when and/or how often logical processors are dispatched. Given these data, the operating system may collect metrics. Using the logical processor metrics, the operating system may determine whether cache affinity is likely to provide a significant performance benefit relative to the cost of dispatching a particular logical processor to the operating system.