Changes between Version 25 and Version 26 of projectstructure

Timestamp:

Jun 16, 2008, 4:59:41 PM (16 years ago)

Author:

fpecheux

Comment:

--

projectstructure

@@ -82 +82 @@
 Based on the online monitoring information that have been gathered by the appropriate monitoring resources (WP1), diagnosed and classified in the Architecture Instant Map Database AIM-DB (WP2) a collection of strategies for improving the application mapping are considered. This self-adaptability scheme may, depending on the system policy, aim at:
 
-* Decreasing the system power consumption
-* Ensuring real-time performance or more generally improving application performance
-* Guaranteeing functionality in the presence of faulty hardware resources
+ * Decreasing the system power consumption
+ * Ensuring real-time performance or more generally improving application performance
+ * Guaranteeing functionality in the presence of faulty hardware resources
 
 These strategies operate on a task basis as per defined by the application task graph. Only the following on-line operations are considered:
 [[BR]]
-*       Migration. Tasks are moved from HW resource to HW resource for :
+ *      Migration. Tasks are moved from HW resource to HW resource for :
   *     Lowering communication cost / power consumption  in order to improve performance if an alternative processing resource has a more appropriate support for a particular task. Additionally, if some of the processing resources have time-sliced execution capabilities (a CPU running a multitasking operating system); migrating tasks results in a higher performance since time is shared among fewer tasks.
   *     Avoiding mapping to a faulty hardware resource, when online diagnostic support identifies an imminent problem occurrence (increased current leakage, temperature rising, etc.) 
 
-*       Replication. Tasks that are identified as critical (forming a bottleneck) can get replicated in order to improve performance, provided that the application description enables it. Replication only occurs when a task becomes critical momentarily meaning that later on, when the performance demand drops below a given threshold replicated tasks are killed freeing the corresponding processing resources.
+ *      Replication. Tasks that are identified as critical (forming a bottleneck) can get replicated in order to improve performance, provided that the application description enables it. Replication only occurs when a task becomes critical momentarily meaning that later on, when the performance demand drops below a given threshold replicated tasks are killed freeing the corresponding processing resources.
 
-*       Router reconfiguration. For either communication performance (avoiding contentions) or for dealing with a hardware defect on some units/physical links, the routing tables may be changed at run-time.
+ *      Router reconfiguration. For either communication performance (avoiding contentions) or for dealing with a hardware defect on some units/physical links, the routing tables may be changed at run-time.
+[[BR]]
 [[BR]]
 The two first classes of operations may take place in different ways: 
-*       a fully centralized scenario where once the decision to remap the application has been taken, a global remapping is issued.
-*       a fully decentralized scenario where processing resources are all equally endowed with decision capabilities.
+ *      a fully centralized scenario where once the decision to remap the application has been taken, a global remapping is issued.
+ *      a fully decentralized scenario where processing resources are all equally endowed with decision capabilities.
 
 Depending on the chosen approach (i.e. centralized or distributed) there may exist tight coupling between the application remapping (current WP) and online diagnosis (WP2). Although a centralized mapping strategy can operate using the system-level information issued by the online diagnosis and drive the corresponding remapping operations, a fully distributed strategy runs differently.