Changes between Version 23 and Version 24 of projectstructure


Ignore:
Timestamp:
Jun 16, 2008, 4:57:32 PM (16 years ago)
Author:
fpecheux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • projectstructure

    v23 v24  
    107107The underlying motivation behind the evaluation of both strategies relies in the problem of scalability. A centralized scenario may intrinsically take better decisions since it operates on a global system view. Nevertheless, the necessary support it requires for periodically retrieving the AIM information implies an overhead which grows larger with the number of processors the system features. The intended explorations will help better defining the best trade-off according to, among other criteria, the number of processors and the desired adaptability.
    108108
     109[[BR]]
     110|| '''Task  3.a''' :  Multi-constrained centralized remapping scenario, Task manager : '''LIP6''', Partners : '''LIP6''', '''LIRMM''', '''LETI'''. In this approach, the information contained in the AIM-DB of WP2 is considered globally. Once the diagnosis has been performed, and the actions to be undertaken (skipping faulty parts in the remapping process, migrating threads to lower temperature on a region of the chip, etc…) clearly identified, a dedicated master processor on the MP2SoC executes the remapping algorithm, taking into account one AIM (single constrained, faulty parts) or several (multi-constrained) AIMs (faulty parts AND temperature AND processor workload, for instance). The remapping is actually   composed of two steps: the remapping step that takes as inputs the application graph and the considered AIMs, and assigns hardware resources to threads, and the application relinking/reloading step that generates a new binary executable, appropriate global/local routing tables, and reloading orders from the collection of object files (thread object files and operating system object files) representing the running application. This way, the MP2SoC is able to self-adapt to a new application firmware.
     111|| T0+12 → T0+36||
     112|| Status : '''not achieved yet'''||
     113
     114[[BR]]
     115|| '''Task  3.b''' :  Multi-constrained distributed remapping scenario, Task manager : '''LIRMM''', Partners : '''LIRMM''', '''LETI'''. This scenario is based on a distributed remapping strategy where each processing resource in the MP2SoC performs all three phases of the self-adaptation scheme in a continuous manner. This scenario therefore triggers remapping orders asynchronously (when a local Boolean condition becomes true for instance) with respect to the other units or clusters which also undergo the same process. Each of these operates according to one of the following principles: 1) local-only AIM database drives remapping decisions. Since remapping orders are issued locally, a lot of effort has to be put into researching adequate remapping policies; specifically because we here consider both migration and replication operations for this phase. 2) global, periodically broadcasted instant map system view guide the remapping process. In this specific case we assume that this global information is potentially outdated. Here again we do consider both migration and replication. 3) An intermediate solution between centralized and fully distributed will also be explored; based on a globally issued placement some regions will undergo locally decided remapping in order to perform local placement refinements For this specific solution, only task migrations are considered.
     116|| T0+12 → T0+36||
     117|| Status : '''not achieved yet'''||
     118
     119[[BR]]
     120|| '''Task  3.c''' :  Mutualized System-level Case studies, Task manager : '''LIRMM''''''''', Partners : '''ALL'''. In order to fairly benchmark the proposed remapping solutions, both centralized and distributed remapping scenarios will be validated on four already existing multi-threaded applications. Applications range from a simple MJPEG application to a complete fourth generation mobile telecommunication system, 3GPP-LTE (Long Term Evolution). H264 and MP3 decoding applications will also be studied. This will help in clearly quantifying the benefits of the proposed approaches as this application is representative of the real applications that MP2SoC will soon have to run. More precisely, the partners will setup a result table with 2 lines (1/centralized, 2/distributed) and four columns (MJPEG, MP3, H264, 3GPP-LTE) and identify scientifically for each table cell the pros and cons of the remapping scenario.
     121|| T0+18 → T0+36||
     122|| Status : '''not achieved yet'''||