1 / 7

Questions To Ask When Considering Designing Asymmetric Multiprocessing Systems

Questions To Ask When Considering Designing Asymmetric Multiprocessing Systems. George Cox. Agenda. Context of Asymmetric Multiprocessing Systems design Including Asymmetric Multicore Systems Closeness Sharing – tight to loose, up the semantics stack

paley
Télécharger la présentation

Questions To Ask When Considering Designing Asymmetric Multiprocessing Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Questions To Ask When Considering Designing Asymmetric Multiprocessing Systems George Cox

  2. Agenda • Context of Asymmetric Multiprocessing Systems design • Including Asymmetric Multicore Systems • Closeness • Sharing – tight to loose, up the semantics stack • Communication overheads – tight to loose physical connection • Closer => less latency => less overheads => • Better performance? • Lower power? Integrating New Functionality • Continuing new types • Natural tendency to want to integrate support to improve • Performance • Power • Cost • Competitiveness

  3. Context • Asymmetric Multiprocessing Systems • Including Asymmetric Multicore Systems • You have a multi-dimensional space in which to work • We will describe a two (2) space example • You must pick the optimal(?) point(s) within your design constraints • You rarely get a “clean sheet of paper” • Historical I/O models – driver-based, “through” data flow • Historical coprocessor models – driver-based, “in and back out” data flow

  4. Sharing • Equivalent shared semantics • Between processing elements • Up the semantics stack • Physical addressing – size, shared or separated, movement between • Logical addressing – address translation (e.g., paging) • Virtual addressing – uniform (or not) swapping model • Caching – same number of levels, line length, sizes, replacement algorithms, consistency model, inter-core/processor handshakes • Processing element functionality • Same ISA (or not) • Virtual machines – uniform semantics, representation, migration across ISA/performance differences

  5. Communication Overheads Tight to loose physical connection – less to more latency • Intra-die • Inter-die • Inter-package • Shared memory • Via bus • Via network

  6. Virtual Machines Processing Element Functionality Caching Virtual Addressing Logical Addressing Physical Addressing Inter Package Shared Memory Via Network Intra-Die Inter-Die Via Bus Design Space Sharing Better? Worse? Communication Overheads

  7. Integrating New Functionality • New types • Cryptography, graphics, radios, sensors • Granularity • Which kind of interface to use • Instruction • Accelerator(s) - ISA (synchronous or asynchronous) interface • I/O – driver (asynchronous) interface • Coprocessor – driver (asynchronous) interface • Sequencing • Synchronous • Long running functions can pose response latency for OS; • Divide function into sequence of smaller functions (e.g., AESNI) • Asynchronous – fork, join • In the end • We have tried lots of kinds of interfaces over time • Instructions (almost always eventually) win

More Related