multicore resource management

.....................................................................................................................................................................................................................................................

MULTICORE RESOURCE MANAGEMENT.....................................................................................................................................................................................................................................................

CURRENT RESOURCE MANAGEMENT MECHANISMS AND POLICIES ARE INADEQUATE FOR

FUTURE MULTICORE SYSTEMS. INSTEAD, A HARDWARE/SOFTWARE INTERFACE BASED ON

THE VIRTUAL PRIVATE MACHINE ABSTRACTION WOULD ALLOW SOFTWARE POLICIES TO

EXPLICITLY MANAGE MICROARCHITECTURE RESOURCES. VPM POLICIES, IMPLEMENTED

PRIMARILY IN SOFTWARE, TRANSLATE APPLICATION AND SYSTEM OBJECTIVES INTO VPM

RESOURCE ASSIGNMENTS. THEN, VPM MECHANISMS SECURELY MULTIPLEX, ARBITRATE,

OR DISTRIBUTE HARDWARE RESOURCES TO SATISFY THE VPM ASSIGNMENTS.

......Continuing the long-term trend ofincreasing integration, the number of coresper chip is projected to increase with eachsuccessive technology generation. Thesechips yield increasingly powerful systemswith reduced cost and improved efficiency.At the same time, general-purpose comput-ing is moving off desktops and onto diversedevices such as cell phones, digital enter-tainment centers, and data-center servers.1

These computers must have the key featuresof today’s general-purpose systems (highperformance and programmability) whilesatisfying increasingly diverse and stringentcost, power, and real-time performanceconstraints.

An important aspect of multicore chips isimproved hardware resource utilization. Ona multicore chip, concurrently executingthreads can share costly microarchitectureresources that would otherwise be under-utilized, such as off-chip bandwidth. Higherresource utilization improves aggregate per-formance and enables lower-cost designalternatives, such as smaller die area or lessexotic battery technology. However, in-creased resource sharing presents a numberof new design challenges. In particular,greater hardware resource sharing amongconcurrently executing threads can cause

individual thread performance to becomeunpredictable and might lead to violationsof the individual applications’ performancerequirements.2,3

Traditionally, operating systems are re-sponsible for managing shared hardwareresources—processor(s), memory, and I/O.This works well in systems where processorsare independent entities, each with its ownmicroarchitecture resources. However, inmulticore chips, processors are concurrentlyexecuting threads that compete with eachother for fine-grain microarchitecture re-sources. Hence, conventional operatingsystem policies don’t have adequate controlover hardware resource management. Tomake matters worse, the operating system’ssoftware policies and the hardware policiesin the independently developed microarch-itecture might conflict. Consequently, thiscompromises operating system policies di-rected at overall system priorities and real-time performance objectives.

In the context of future applications, thisposes a serious system design problem,making current resource managementmechanisms and policies no longer ade-quate for future multicore systems. Policies,mechanisms, and the interfaces betweenthem must change to fit the multicore era.

Kyle J. Nesbit

James E. Smith

University of Wisconsin

–Madison

Miquel Moreto

Polytechnic University of

Catalonia

Francisco J. Cazorla

Barcelona Supercomputing

Center

Alex Ramirez

Mateo Valero

Barcelona Supercomputing

Center and Polytechnic

University of Catalonia

.......................................................................

6 Published by the IEEE Computer Society 0272-1732/08/$20.00 G 2008 IEEE

In this article, our vision for resourcemanagement in future multicore systemsinvolves enriched interaction between sys-tem software and hardware. Our goal is forthe application and system software tomanage all the shared hardware resourcesin a multicore system. For example, adeveloper or end user will specify anapplication’s quality-of-service (QoS) objec-tives, and the developer or system softwarestack will translate these objectives intohardware resource assignments. BecauseQoS objectives are often application specif-ic, the envisioned multicore architectureprovides an efficient and general interfacethat can satisfy QoS objectives over a rangeof applications. By enriching the interactionbetween hardware and software, the envi-sioned resource management frameworkfacilitates a more efficient, better perform-ing platform design.

Designing general-purpose systems re-quires a clear separation of policies andmechanisms.4 Policies provide solutions; forflexibility, we strive for policies implement-ed in software. Mechanisms provide theprimitives for constructing policies. Becauseprimitives are universal, system designerscan implement mechanisms in both hard-ware and software. In general, mechanismsthat interact directly with fine-grain hard-ware resources should be implemented inhardware; to reduce hardware cost, mecha-nisms that manage coarse-grain resourcesshould be implemented in software.

Virtual private machinesIn a traditional multiprogrammed sys-

tem, the operating system assigns eachapplication (program) a portion of thephysical resources—for example, physicalmemory and processor time slices. From theapplication’s perspective, each applicationhas its own private machine with acorresponding amount of physical memoryand processing capabilities. With multicorechips containing shared microarchitecture-level resources, however, an application’smachine is no longer private, so resourceusage by other, independent applicationscan affect its resources.

Therefore, we introduce the virtualprivate machine (VPM) framework as a

means for resource management in systemsbased on multicore chips.3 VPMs are similarin principle to classical virtual machines.However, classical virtual machines virtua-lize a system’s functionality5 (ignoringimplementation features), while VPMsvirtualize a system’s performance and powercharacteristics, which are implementationspecific. A VPM consists of a complete setof virtual hardware resources, both spatial(physical) resources and temporal resources(time slices). These include the sharedmicroarchitecture-level resources. By defini-tion, a VPM has the same performance andpower characteristics as a real machine withan equivalent set of hardware resources.

The VPM abstraction provides the con-ceptual interface between policies andmechanisms. VPM policies, implementedprimarily in software, translate applicationand system objectives into VPM resourceassignments, thereby managing system re-sources. Then, VPM mechanisms securelymultiplex, arbitrate, or distribute hardwareresources to satisfy the VPM assignments.

Spatial componentA VPM’s spatial component specifies the

fractions of the system’s physical resourcesthat are dedicated to the VPM during thetime(s) that it executes a thread. For example,consider a baseline system containing fourprocessors, each with a private L1 cache. Theprocessors share an L2 cache, main memory,and supporting interconnection structures.Figure 1 shows that the policy has distribut-ed these resources among three VPMs. VPM1 contains two processors, and VPMs 2 and3 each contain a single processor. The policyassigns VPM 1 a significant fraction (50percent) of the shared resources to support ademanding multithreaded multimedia ap-plication and assigns the other two VPMsonly 10 percent of the resources. Theseassignments leave 30 percent of the cacheand memory resources unallocated; theseresources are called excess service. Excessservice policies distribute excess service toimprove overall resource utilization andoptimize secondary performance objectives.

In our example, we focus on sharedmemory hierarchy resources, but VPMconcepts also apply to internal processor

........................................................................

MAY–JUNE 2008 7

resources, such as issue buffers, load/storequeue entries, and instruction decode andexecution bandwidth.2 Furthermore, we canapply the same concepts to architectedresources such as memory capacity and I/O.

As Figure 1 illustrates, a VPM’s spatialcomponent might contain multiple proces-sors. Multiprocessor VPMs are a naturalextension of gang scheduling and supporthierarchical resource management.6,7 Forexample, schedulers and resource manage-ment policies running within a multipro-cessor VPM can schedule and manage theVPM’s processors and resources as if theVPM were a real multiprocessor machine.That is, multiprocessor VPMs can supportrecursive virtualization.5

Temporal componentA VPM’s temporal component is based

on the well-established concept of ideal

proportional sharing.8 It specifies the frac-tion of processor time (processor time slices)that a VPM’s spatial resources are dedicatedto the VPM (see Figure 2). As with spatialVPM resources, a VPM’s temporal compo-nent naturally lends itself to recursivevirtualization and hierarchical resourcesmanagement, and excess temporal servicemight exist.

Minimum and maximum VPMsTo satisfy objectives, policies might

assign applications minimum or maximumVPMs, or both, depending on the objec-tives. Mechanisms ensure an application isoffered a VPM that is greater than or equalto the application’s assigned minimumVPM. (We precisely define the greater thanor equal to VPM ordering relationshipelsewhere.3) Informally, the mechanismsoffer an application at least the resources

Figure 1. Virtual private machine (VPM) spatial component. The policy has distributed the

multicore chip’s resources among three VPMs. After assigning VPM 1 50 percent of the

shared resources and VPMs 2 and 3 each 10 percent, it leaves 30 percent of the cache and

memory resources unallocated for excess service.

.........................................................................................................................................................................................................................

ARCHITECTURE-OS INTERACTION

.......................................................................

8 IEEE MICRO

of its assigned minimum VPM. Whencombined with the assumption that anapplication will only perform better if it isoffered additional resources (performancemonotonicity9), ensuring a minimum VPMassignment leads to desirable performanceisolation; that is, the application running onthe VPM performs at least as well as itwould if it were executing on a real machinewith a configuration equivalent to theapplication’s assigned VPM. This perfor-mance level is assured, regardless of theother applications in the system.

Mechanisms can also ensure an applica-tion receives no more than its maximumVPM resources. Policies can use maximumVPM assignments to control applications’power consumption, which is based on theassumption that an application’s powerconsumption is a monotonically increasingfunction of its resource usage (powermonotonicity). For maximum VPM assign-ments to improve power savings significant-ly, they should be supported by mechanismsthat power down unused resources. Fur-thermore, because temperature and transis-tor wear-out strongly depend on powerconsumption, policies can use maximum

VPMs to control temperature and lifetimereliability.10 Lastly, application developerscan use maximum VPMs to test whether aminimum VPM configuration satisfies anapplication’s real-time performance require-ments.9

PoliciesVPM assignments satisfy real-time per-

formance, aggregate performance, power,temperature, and lifetime reliability objec-tives. Overall, the VPM policy design spaceis enormous and is a fertile area for futureresearch. Here, we begin with a high-leveloverview of the policy design space and thendiscuss the basic types of policies and howthey interact in our envisioned systemarchitecture.

In general, we envision two basic types ofpolicies. Application-level policies satisfy anapplication’s QoS objectives by translatingthe QoS objectives into a VPM configura-tion as well as scheduling and managingVPM resources assigned to the application.System policies satisfy system objectives bycontrolling the distribution of VPM re-sources among applications. System policiescontrol resource distribution by grantingand rejecting requests for VPM resourcesand revoking VPM resources when thesystem is overloaded.

The policy architecture’s main feature isits extensibility (see Figure 3, next page): weclearly separate policies and mechanisms,4

and policies are easy to replace or modify ona per system and per application basis.11 Forexample, in Figure 3, a system is runningfive applications, each within its own VPM(not shown). The first application (on theleft) is a real-time recognition application.To satisfy its real-time requirements, theapplication is running with an application-specific VPM that the application’s devel-oper computed offline. The second andthird applications (mining and synthesis)are written in a domain-specific, concurrentprogramming language. The language in-cludes a runtime that computes VPMconfigurations online and optimizes appli-cations’ concurrency in coordination withthe applications’ VPM resources. Themining and synthesis applications are iso-lated from each other, but they share the

Figure 2. VPMs consist of a spatial

component and a temporal component.

The temporal component specifies the

fraction of processor time that a VPM’s

spatial resources are dedicated to

the VPM.

........................................................................

MAY–JUNE 2008 9

library code that implements the language’sruntime. The last two applications (MySQLand Apache) are standard Linux applica-tions that are oblivious to the underlyingsystem’s VPM support. The applications arerunning on a paravirtualized version ofLinux, which in turn is running on a thinsoftware layer that monitors the applica-tions’ workload characteristics and roughly

computes VPM configurations using heu-ristics and ad hoc techniques. Most impor-tantly, application-level policies allow ap-plication developers and runtime libraries tocustomize a system’s behavior to satisfy arange of applications’ requirements.

Application-level policiesIn general, there are two logical steps for

determining VPM assignments: modelingand translation. We describe the steps asseparate phases, although in practice theymay be combined. As we described earlier,application policies compute VPM config-urations either online (automated) or offline(manually). Online policies are based pri-marily on runtime analysis (for example, byusing performance counters), while offlinepolicies require an application developer toperform most of the program analysis.Online/offline hybrid policies are alsofeasible.

In addition, application policies can usestandardized application-level abstractionlayers that provide developers with abstractmachine models. Such models are oftenimplementation independent and have per-formance characteristics that are easier fordevelopers to reason about (see Figure 4).

VPM modeling. The VPM modeling stepmaps application QoS objectives, such asminimum performance and maximumpower, to VPM configurations. The sophis-tication of VPM modeling techniques spansa fairly wide range. At one end are simple,

Figure 3. The VPM system architecture consists of application-level policies, system

policies, software mechanisms, and hardware mechanisms. The extensible policy

architecture lets policy builders modify policies on a per system and per application basis.

Figure 4. Application policies compute VPM configurations in two logical

steps: VPM modeling and translation. Standardized application-level

abstractions can be used to abstract away irrelevant implementation-

specific VPM details.

.........................................................................................................................................................................................................................


.......................................................................

10 IEEE MICRO

general-purpose analytical models that usegeneric online profiling information toroughly predict an application’s perfor-mance and power when running on differ-ent VPM configurations. At the other endare models specialized to a specific applica-tion (or a domain of applications) throughoffline profiling and characterization. Suchoffline models can precisely capture anapplication’s performance and power ondifferent VPM configurations.

Application- or domain-specific VPMmodeling can provide more precise predic-tions but might require more developereffort—for example, to determine suitableVPM configurations offline. Applicationswith critical QoS objectives (such as real-time applications) will generally requiremore precise VPM modeling.

VPM translation. The VPM translationstep uses the VPM models to find VPMconfigurations that satisfy an application’sQoS objectives. Multiple VPM configura-tions can satisfy the same objective. Forexample, multiple minimum VPM config-urations can satisfy a single real-timeperformance objective; that is, one suitableVPM configuration might have a largerspatial component and smaller temporalcomponent, while another suitable VPMmight have a larger temporal componentand smaller spatial component. Or theremight be different combinations of resourc-es within the spatial component.

Furthermore, applications might havemultiple objectives that a policy can use toprune the number of suitable VPM config-urations. For example, an application policycan search for a VPM configuration thatsatisfies a real-time performance require-ment and minimizes power consumption.Moreover, a policy can assign an applicationa maximum VPM to bound the applica-tion’s power consumption. In many practi-cal situations, finding the optimal VPMconfiguration is NP-hard. Consequently,online translation generally must use ap-proximate and heuristic-based optimizationtechniques. For applications with criticalQoS objectives, the application developercan do a portion of the VPM translationoffline. Moreover, the developer can com-

bine the VPM modeling and translationsteps into a single step. For example, anapplication developer might use maximumVPM assignments and trial and error tocompute a minimum VPM configurationthat satisfies their application’s real-timeperformance objective.9

Once the policy has found a suitableVPM configuration, it initiates a request tothe system’s policies for the VPM resources.If the VPM resources are available, thesystem policies securely bind the VPMresources to the application.11 When asystem is heavily loaded, the system policiesmight reject an application’s VPM requestor revoke a previous VPM resource binding.

An application policy must implement aprocedure for handling VPM rejections andrevocations. When a rejection or revocationoccurs, an application policy can findanother suitable VPM configuration orreconfigure the application to reduce theapplication’s resource requirements. Forexample, a real-time media player candowngrade its video quality or simplyreturn an insufficient resource error messageand exit.

To help with global (systemwide) re-source optimization, VPM system policiescan provide feedback to the applications’policies. The feedback informs the applica-tions of global resource usage. An applica-tion’s policies can use the system feedbackinformation to further prune the suitableVPM configurations and find a VPM that isamenable to systemwide resource con-straints. In addition, an application’s poli-cies can use VPM modeling and onlineprofiling information to dynamically re-spond to changing workload characteristics.

VPM abstraction layer. In our discussionso far, we’ve assumed a relatively high-levelVPM abstraction—for example, VPMs thatconsist of shares of cache bandwidth, cachestorage, and memory system bandwidth.However, real hardware resources are morecomplex. For example, a physical cacheimplementation consists of banks, sets, andways. VPM mechanisms don’t abstracthardware resources; that is, the VPMmechanisms convey implementation specif-ic details to the application policies. Expos-

........................................................................

MAY–JUNE 2008 11

ing implementation details creates an inter-face that’s more efficient to implement andgrants more latitude to implementers ofhigher-level abstractions.11

However, exposing implementation de-tails to applications can make applicationsimplementation dependent. Moreover,many application policies don’t need low-level implementation details to satisfy theirQoS objectives. To improve applicationcompatibility, many application policies canuse standardized VPM abstraction layers. AVPM abstraction layer provides a high-levelVPM that abstracts away a system’s imple-mentation-specific details while capturingthe system’s first-order performance andpower characteristics. At runtime, theabstraction layer efficiently translates high-level VPM configurations into low-levelVPM assignments that the system’s mech-anisms support.

System policiesSystem policies control the distribution

of VPM resources by brokering applica-tions’ VPM requests. System policies havethree basic components: a system monitor,feedback policies, and excess service policies(see Figure 5).

System monitor. The system monitortracks the load on the system’s resourcesand detects system overload. A system isoverloaded if it doesn’t have enoughresources to satisfy its applications’ VPM

assignments. In general, it’s best to detectoverload as early as possible, such as whenan application initiates a VPM request thatcauses the system to become overloaded. Todetect system overload, the system mustmonitor any shared resource that canbecome overloaded, such as cache storage,execution bandwidth, cooling capacity, andpower delivery. We can detect that a VPMrequest overloads a system’s physical re-sources with an admission control test. Forexample, the system monitor can comparethe set of dedicated VPM resources with thecapacity of the system’s physical resources.

Detecting that a VPM request overloads asystem’s less tangible resource constraints(such as a power-delivery system, coolingcapacity, or transistor lifetime reliability) ismore difficult. The system monitor mustuse VPM models to translate between lesstangible resource constraints and VPMconfigurations. The VPM models shouldbe accurate enough to detect most overloadconditions at the time an applicationinitiates a VPM request; however, theydon’t have to be completely accurate. Thesystem monitor’s VPM models are used tosupplement conventional hardware sensors,such as voltage and temperature sensors.Hardware sensors can detect anomalousoverload conditions (such as overheating)in real time and prevent catastrophicfailures. If a sensor detects an overloadedresource, the system policies have acceptedmore VPM requests than the system’sphysical resources can satisfy. In this case,the system policies must revoke someapplications’ assigned VPM resources.

Feedback policies. Feedback policies deter-mine which applications’ VPM resourcesshould be rejected or revoked when thesystem is overloaded. For example, when asystem is overloaded, a feedback policymight reject any incoming VPM requestor revoke the VPM resources of theapplication with the lowest user-assignedpriority. Feedback policies also informapplications of systemwide resource utiliza-tion and the cause(s) of rejected or revokedVPM requests—for example, the systemmight have insufficient power resourcesavailable.

Figure 5. System policies broker VPM requests and monitor application

resource usage to ensure that the system does not become overloaded.

.........................................................................................................................................................................................................................


.......................................................................

12 IEEE MICRO

As we described earlier, applications’policies can use the feedback to compute asuitable VPM configuration that’s amenableto systemwide resource usage. The feedbackpolicies should also provide applicationswith up-to-date systemwide resource usageinformation regardless of VPM rejectionsand revocations. This way the feedbackpolicies can direct global optimization of asystem’s resource usage.

Excess service policies. After application andsystem policies have settled on a suitable setof VPM assignments, there might be excessservice available. Excess service is servicethat is unassigned or assigned but unused bythe application to which it’s assigned. Excessservice policies distribute excess service tooptimize system objectives. For example,these policies can distribute service toimprove response time or throughputaveraged over all applications, to conservepower or transistor lifetime, or a combina-tion of such objectives. To optimize poweror transistor lifetime objectives, excessservice policies prevent applications fromconsuming the excess service. That is, thesepolicies assign tasks maximum VPMs, thuscausing the excess resources to be poweredoff. Excess service policies must also ensurethat distributing excess service doesn’tviolate applications’ maximum VPM as-signments.

In most cases, excess service policiestransparently adjust applications’ VPMassignments. For example, they can trans-parently increase a minimum VPM assign-ment or decrease a maximum VPM assign-ment without violating the applicationpolicy’s VPM assignments. For some re-sources, the policies must notify an appli-cation’s policies when excess resources areadded—for example, they must notify anapplication’s thread scheduler when proces-sors are added to a VPM.

For some resources, excess service be-comes available and must be distributed at afine time granularity, such as with SDRAMmemory system bandwidth. In such cases, aportion of the excess service policy must beimplemented in hardware. However, apolicy’s hardware portion should be simple,parameterized, and general; that is, it should

work with multiple software excess-servicepolicies.

MechanismsThere are three basic types of mecha-

nisms needed to support the VPM frame-work: a VPM scheduler, partitioning mech-anisms, and feedback mechanisms (seeFigure 6). The first two types securelymultiplex, arbitrate, or distribute hardwareresources to satisfy VPM assignments. Thethird provides feedback to application andsystem policies. Because mechanisms areuniversal, system builders can implementmechanisms in both hardware and software.Generally, the VPM scheduler is imple-mented in software (in a microkernel11 or avirtual machine monitor12), while the par-titioning mechanisms and feedback mecha-nisms are primarily implemented in hard-ware. Although a basic set of VPMmechanisms are available,2,3 many researchopportunities remain to develop moreefficient and robust VPM mechanisms.

VPM schedulerThe VPM scheduler satisfies applications’

temporal VPM assignments by time-slicinghardware threads.3 The VPM scheduler is aproportional-fair (p-fair) scheduler,13 but itmust also ensure that coscheduled applica-tions’ spatial resource assignments don’tconflict—that is, that the set of coscheduledthreads’ spatial resource assignments matchthe physical resources available and don’toversubscribe any microarchitecture re-

Figure 6. VPM mechanisms are implemented in hardware and software.

The mechanisms satisfy VPM resource assignments and provide feedback

regarding individual application and systemwide resource usage.

........................................................................

MAY–JUNE 2008 13

sources. VPM scheduling in its full gener-ality, satisfying proportional fairness with-out spatial conflicts, is an open researchproblem.3

When the VPM scheduler contextswitches an application onto a processor(or a group of processors), the schedulercommunicates the application’s spatialVPM assignment to the hardware partition-ing mechanisms through privileged controlregisters. Once the control registers areconfigured, the VPM resources are securelybound to the application. Secure bindingdecouples the authorization from resourceusage11—that is, once a resource is securelybound to an application, the application’spolicies can schedule and manage its VPMresources without reauthorization. This wayVPMs can efficiently support hierarchicalscheduling.6

The VPM scheduler we describe here is afirst-level scheduler (or root scheduler), andapplication-level schedulers are second-levelschedulers. Hierarchical scheduling is usefulfor satisfying different classes of QoSrequirements.6 Furthermore, precise appli-cation-level schedulers will play an impor-tant role in future parallel programmingmodels.

Partitioning mechanismsTo satisfy the spatial component of VPM

assignments, each shared microarchitectureresource must be under the control of apartitioning mechanism that can enforceminimum and maximum resource assign-ments. As we described earlier, the resourceassignments are stored in privileged controlregisters that the VPM scheduler configures.In general, each shared microarchitectureresource is one of three basic types ofresources: a memory storage, buffer, orbandwidth resource. Each type of resourcehas a basic type of partitioning mechanism.For example, thread-aware replacementalgorithms partition storage resources (mainmemory and cache storage3,14), upstreamflow control mechanisms partition bufferresources (issue queue and miss statushandling registers2), and fair-queuing andtraffic-shaping arbiters partition bandwidthresources (execution and memory ports3).These basic techniques combined with the

proper control logic can sufficiently enforceminimum and maximum resource assign-ments.

For maximum VPM assignments to beuseful, the partitioning mechanisms must beaccompanied by mechanisms to powerdown resources during periods of inactivity.An example would be, mechanisms thatclock-gate unused pipeline stages and tran-sition inactive memory storage resourcesinto a low-power state. As we mentionedearlier, by controlling resources’ powerconsumption, policies can control otherimportant characteristics such as die tem-perature and transistor wear out.5

Feedback mechanismsMechanisms also provide application and

system policies with feedback regardingphysical resource capacity and usage. Feed-back mechanisms communicate to systempolicies the capacity of the system’s resourc-es and the available VPM partitioningmechanisms. They also provide applicationpolicies with information regarding indi-vidual applications’ resource usage.

Application resource usage informationshould be independent of the systemarchitecture and the application’s VPMassignments. For example, a mechanismthat measures a stack distance histogram canpredict cache storage and memory band-width usage for many different cache sizes.14

Lastly, feedback mechanisms provideinformation regarding overall resource uti-lization. For example, a system’s mecha-nisms should provide system policies withdie-temperature and power-consumptioninformation.

Overall, the VPM framework provides asolid foundation for future architec-

ture research, but many challenges remainin evaluating the VPM framework. First,the framework targets system-level metricsthat occur over time granularities thatpreclude the use of simulation. Second,many of the applications we’re interested in(such as smart phone or cloud computerapplications) are unavailable or unknown.To address these problems, we plan todevelop most of the framework mathemat-ically. (The basis of the mathematical

.........................................................................................................................................................................................................................


.......................................................................

14 IEEE MICRO

framework is available elsewhere.3) We planto validate the mathematical framework andassumptions using statistical simulation. Inturn, we plan to validate the statisticalmethods by prototyping the envisionedsystem architecture and policies inFPGAs. MICRO

................................................................................................

References1. S. Lohr and M. Helft, ‘‘Google Gets Ready

to Rumble with Microsoft,’’ New York

Times, 16 Dec. 2007; www.nytimes.com/

2007/12/16/technology/16goog.html.

2. F.J. Cazorla et al., ‘‘Predictable Performance

in SMT Processors: Synergy between the

OS and SMTs,’’ IEEE Trans. Computers,

vol. 55, no. 7, Jul. 2006, pp. 785-799.

3. K.J. Nesbit, J. Laudon, and J.E. Smith,

Virtual Private Machines: A Resource Ab-

straction for Multicore Computer Systems,

tech. report 07-08, Electrical and Computer

Engineering Dept., University of Wiscon-

sin–Madison, Dec. 2007.

4. R. Levin et al., ‘‘Policy/Mechanism Separa-

tion in Hydra,’’ Proc. 5th ACM Symp.

Operating Systems Principles (SOSP 75),

ACM Press, 1975, pp. 132-140.

5. G.J. Popek and R.P. Goldberg, ‘‘Formal

Requirements for Virtualizable Third Gener-

ation Architectures,’’ Comm. ACM, vol. 74,

no. 7, Jul. 1974, pp. 412-421.

6. P. Goyal, X. Guo, and H.M. Vin, ‘‘A

Hierarchical CPU Scheduler for Multimedia

Operating Systems,’’ SIGOPS Operating

Systems Rev., vol. 30, no. SI, Oct. 1996,

pp. 107-121.

7. J.K. Ousterhout, ‘‘Scheduling Techniques

for Concurrent Systems,’’ Proc. Int’l Conf.

Distributed Computing Systems (ICDCS

82), IEEE CS Press, 1982, pp. 22-30.

8. A.K. Parekh and R.G. Gallager, ‘‘A General-

ized Processor Sharing Approach to Flow

Control in Integrated Services Networks: The

Single-Node Case,’’ IEEE/ACM Trans. Net-

works, vol. 1, no. 3, Jun. 1993, pp. 344-357.

9. J.W. Lee and K. Asanovic, ‘‘METERG:

Measurement-Based End-to-End Perfor-

mance Estimation Technique in QoS-Capa-

ble Multiprocessors,’’ Proc. 12th IEEE Real-

Time and Embedded Technology and Ap-

plications Symp. (RTAS 06), IEEE CS Press,

2006, pp. 135-147.

10. A.S. Sedra and K.C. Smith, Microelectronic

Circuits, 5th ed., Oxford Univ. Press, 2004.

11. D.R. Engler, M.F. Kaashoek, and J. O’Toole,

‘‘Exokernel: An Operating System Archi-

tecture for Application-Level Resource

Management,’’ Proc. 15th ACM Symp.

Operating Systems Principles (SOSP 95),

ACM Press, Dec. 1995, pp. 251-266.

12. J. Smith and R. Nair, Virtual Machines:

Versatile Platforms for Systems and Pro-

cesses, Morgan Kaufmann, 2005.

13. S.K. Baruah et al., ‘‘Proportionate Progress:

A Notion of Fairness in Resource Alloca-

tion,’’ Proc. 25th ACM Symp. Theory of

Computing (STOC 93), ACM Press, 1993,

pp. 345-354.

14. G.E. Suh, S. Devadas, and L. Rudolph, ‘‘A

New Memory Monitoring Scheme for

Memory-Aware Scheduling and Partition-

ing,’’ Proc. 8th Int’l Symp. High-Perfor-

mance Computer Architecture (HPCA 02),

IEEE CS Press, 2002, pp. 117-128.

Kyle J. Nesbit is a PhD candidate in theDepartment of Electrical and ComputerEngineering at the University of Wiscon-sin–Madison. His research interests includecomputer architecture and virtual machines,particularly multicore architectures andresource management for emerging plat-forms. Nesbit received his BS in computerengineering from the University of Wiscon-sin–Madison.

Miquel Moreto is a PhD candidate in theComputer Architecture Department at thePolytechnic University of Catalonia, Spain.His research interests include modelingparallel computers and resource sharing inmultithreaded architectures. Moreto re-ceived his MS in both mathematics andelectrical engineering from the PolytechnicUniversity of Catalonia.

Francisco J. Cazorla is the leader of theOperating System/Computer ArchitectureInterface group at the Barcelona Super-computing Center. His research focuses onmultithreaded architectures for both high-performance and real-time computing sys-tems. Cazorla received his PhD in Com-puter Architecture from the PolytechnicUniversity of Catalonia.

........................................................................

MAY–JUNE 2008 15

Alex Ramirez is an associate professor at thePolytechnic University of Catalonia andresearch manager at the Barcelona Super-computing Center. Research interests in-clude heterogeneous multicore architec-tures, hardware support for programmingmodels, and simulation techniques. Hereceived his PhD in computer science fromthe Polytechnic University of Catalonia.

Mateo Valero is a professor at the Poly-technic University of Catalonia and directorof the Barcelona Supercomputer Center.His research interests include high-perfor-mance architectures. Valero has a PhD intelecommunications from the PolytechnicUniversity of Catalonia. He is a recipient ofthe Eckert-Mauchly Award and a foundingmember of the Royal Spanish Academy ofEngineering. He is an IEEE Fellow, an IntelDistinguished Research Fellow, and anACM Fellow.

James E. Smith is a professor emeritus inthe Department of Electrical and ComputerEngineering at the University of Wiscon-sin–Madison and a member of the technicalstaff at Google. His current researchinterests include high-performance andpower-efficient processor implementations,processor performance modeling, and vir-tual machines. Smith has a PhD incomputer science from the University ofIllinois.

Direct questions and comments aboutthis article to Kyle J. Nesbit, Univ. ofWisconsin–Madison, 2420 EngineeringHall, 1415 Engineering Dr., Madison, WI53706-1691; [email protected].

For more information on this or any

other computing topic, please visit our

Digital Library at http://computer.org/

csdl.

.........................................................................................................................................................................................................................


.......................................................................

16 IEEE MICRO

multicore resource management

Documents