The Landscape of Seven Questions and Seven Dwarfs for Parallel Computing Research: a view from Berkeley
Operating system support via Virtual Machines
Download 232.56 Kb.
|
- Navigate this page:
- 6.0 Metrics for Success
- 6.1 Maximizing programmer productivity
- 6.2. Maximizing application efficiency
5.5 Operating system support via Virtual Machines[[Editor: We’d appreciate comments on this section, as we’re not quite sure we’ve got this right. Instead of or in addition to VMs, we could mention separations of control plane and data plane, front-end processor, …]] One place where the tension between the embedded and server communities is the highest is in operating systems. Embedded applications have historically run with very thin OSes while server applications often rely on OSes that contain millions of lines of code. Virtual Machines (VMs) may be the compromise that is attractive to both camps. VMs provide a software layer that lets a full OS run above the VM without realizing that layer is being used. This layer is called a Virtual Machine Monitor (VMM) or hypervisor. This approach allows a very small, very low overhead VMM to provide innovative protection and resource sharing without having to run or modify multimillion line OSes. VMs have become popular recently in server computing for a few reasons: [Hennessy and Patterson, 2006]
Since embedded computers are increasingly connected by networks, we think they will be increasingly vulnerable to viruses and other attacks. As embedded software grows over time, it may prove advantageous to run different programs in different VMs to make the system resilient to software failures. Finally, as mentioned in CW # 3 in Section 2, high soft and hard error rates will become a standard problem for all chips at feature sizes of 65 nm or below. The ability of VMs to move from a failing processor to a working processor in a manycore chip may also be valuable in future embedded applications. The overhead of running an OS on a VMM is generally a function of the instruction set architecture. By designing an ISA to be virtualizable, the overhead can be very low. Hence, if we need new ISAs for manycore architectures, they should be virtualizable. Since embedded computing is following some of the same software engineering challenges as the size of the software grows, we recommend putting in the hooks to be able to run VMM with low overhead. If future of manycore is a common architecture for both embedded and sever computing, a single architecture could run either a very thin or a very thick OS depending on the needs of the application. Moreover, the cost to enable efficient VMs are so low that there is little downside to accommodating them even if they never gain popularity in embedded computing. 6.0 Metrics for SuccessHaving covered the six questions from the full bridge in Figure 1, we need to decide how to best invent and evaluate answers to those questions. In the following we focus on maximizing two metrics: programmer productivity and final implementation efficiency. 6.1 Maximizing programmer productivityHaving thousands of processing elements on a single chip presents a major programming challenge to application designers. The adoption of the current generation of on-chip multiprocessors has been slow due to the difficulty of getting applications correctly and productively implemented on these devices. For example, the adoption of on-chip multiprocessors targeted for network applications has been slowed due to the difficulty of programming these devices. The trade press speaking of this generation of devices says [Wienberg 2004] “... network processors with powerful and complex packet-engine sets have proven to be notoriously difficult to program.” Earlier on-chip multiprocessors such as the TI TMS320C80 failed altogether due to their inability to enable application designers to tap their performance productively. Thus, the ability to productively program these high performance multiprocessors of the future is as at least as important as providing high-performance silicon implementations of these architectures. Productivity is a multifaceted term that is difficult to quantify. However, case studies such as [Shah et al 2004b] build our confidence that productivity is amenable to quantitative comparison. 6.2. Maximizing application efficiencyOne implication of Figure 2 is that for the last twenty years application efficiency steadily increased simply by running applications on new generations of processors with minimal additional programmer effort. As processor efficiency has slowed, new ideas will be required to realize application efficiency. Radical ideas are required to make manycore architectures a secure and robust base for productive software development since the existing literature only shows successes in narrow application domains such as Cisco’s 188-processor Metro chip for networking applications [Eatherton 2005]. The interactions between massively parallel programming models, real-time constraints, protection, and virtualization provide a rich ground for architecture and software systems research. We believe it is time to explore a large range of possible machine organizations and programming models, and this requires the development of hardware prototypes as otherwise there will be no serious software development. Moreover, since the power wall has forced us to concede the battle for maximum performance of individual processing elements, we must aim at winning the war for application efficiency through optimizing total system performance. This will require extensive design space exploration. The general literature on design-space-exploration is extensively reviewed in [Gries 2004] and the state-of-the art in commercial software support for embedded processor design-space exploration using CoWare or Tensilica toolsets is presented in [Gries and Keutzer 2005]. However, evaluating full applications requires more than astute processing element definition; the full system-architecture design space including memory and interconnect must be explored. Although these design space explorations focus on embedded processors, we believe that the processors of manycore systems will look more like embedded processors than current desktop processors (see Section 4.1.2.) New efficiency metrics will make up the evaluation of the new parallel architecture. As in the sequential world there are many “observables” from program execution that provide hints (much like cache misses) to the overall efficiency of a running program. In addition to serial performance issues, the evaluation of parallel systems architectures will focus on:
Software design environments for embedded systems such as those described in [Rowen and Leibson 2004] lend greater support to making these types of system-level decisions, but we are skeptical that software simulation alone will provide sufficient throughput for thorough evaluation of a manycore systems architecture. Nor will per-project hardware prototypes that require long development cycles be sufficient. The development of these ad hoc prototypes will be far too slow to develop to influence the decisions that industry will need to make regarding future manycore system architectures. We need a platform where feedback from software experiments on novel manycore architectures running real applications with representative workloads will lead to new system architectures within days not years. Directory: images images -> Pelan pentaksiran kursus images -> Military callsign list as of dec 2010 images -> For Date: 02/01/2013 Friday Call Number Time Call Reason Action 13-768 0008 motor vehicle stop warning Issued images -> New embedded S images -> Creating Buy-In – Building Relationships images -> Deadline: Saturday, March 12th, 2016 images -> News items from Raising Our Voices images -> Last year four of the best Afrikaans Christian singers joined forces to tour Down Under with the production ‘Manne wat Glo’ images -> World-renowned vocal ensemble sweet honey in the rock images -> Peoples Voice Café History Download 232.56 Kb. Share with your friends:
|