Changes

Jump to: navigation, search
Conclusions and future work
* Moderate RTOS activity has no impact on latency.
* As expected, in case intensive memory activity is performed on RTOS side, data/instruction cache misses increase significantly resulting in higher latency.
===Isolation vs performances===
This work confirmed the need to find a trade-off between two requirements that often push in opposite directions: isolation and performances. On one hand isolation should be pushed to the maximum possible extent to preserve the integrity of W1 world. On the other hand, overall systems performances have not to be affected so much that the product gets unusable. Generally speaking, strong isolation negatively impacts performances, so finding the optimal balancing is not trivial. A "one size fits all" solution does not exist and system designer is responsible to choose which direction this knob has to be moved. This analysis naturally has to take into account application-specific requirements.
===Future work===
Future work will first focus on an additional feature that has not been included in the requirement list but that is undoubtedly useful in several applications. We are referring to the possibility of performing a complete reboot of the GPOS under the control of the RTOS, while this keeps operating normally. For instance this can be exploited when the RTOS needs to work as software watchdog for W2 activity: in case no activity is detected for a certain period of time, GPOS can be shutdown and rebooted.
Another aspect that should be investigated in more depth refers to the effects of the communication between W1 and W2 on the IRQ latency and the integrity of the real-time world. This matter is strictly related to the degree of isolation between the two worlds. In this work a strong-isolation approach has been adopted, meaning that
*no data is exchanged during the execution of the IRQ latency measurement
*it has been implicitly assumed that data sent from W2 to W1 can not compromise the integrity of the trust domain.
These assumption may be not verified in real applications, however specific techniques can be implemented to manage these situations (see for example <ref name="Sangorrin's thesis"></ref> and <ref name="PreventingInterruptOverload">J. Regehr, U. Duongsaa, ''Preventing Interrupt Overload'', 2nd May 2005, www.cs.utah.edu/~regehr/papers/lctes05/regehr-lctes05.pdf</ref>).
-----
{{notelist}}
4,650
edits

Navigation menu