Description
 

Problem

The time it takes from that the external unit signals an interrupt to the time it’s handled by the software is called interrupt latency. It’s often of major importance that this latency should be as short as possible. The CPU, it’s cache organization, the operating system, the device drivers and even the applications being run strongly affects the interrupt latency of the system. Research on how to use the cache memory to improve the maximal interrupt latency is almost missing completely today. Despite the fact that it’s of major importance for many users of real-time operating systems. The research that exists has no relation to and cannot be applied on the real systems that are being built by industry. Today’s modern processor architectures make this problem much more difficult then it has been in earlier processor generations.

It is clear that the interrupt latency in a system can be shortened by locking parts of code into the cache. But this will probably have negative effects on the performance of the rest of the system, but how much? How much code needs to be looked into the cache to get an improvement that is noticeable and guaranteed? How do you identify what code should be locked? Can locking in the data cache also improve performance of the system? And could the cache locality be done better in the interrupt handling of the operating system.

Another way to improve the interrupt latency is to reduce the longest region where interrupts are disabled in the operating system, device drivers, memory protection system and the application. The longest region probably contains a complex behavior with a lot of iterations and a great number of conditional branches. A thorough analysis of what causes a certain code sequence to have a long execution time is needed. An example of such a region is the scheduler of the operating system.
 
 

Goal

The goal of the thesis project is to research if the cache could be used to reduce the interrupt latency in real life industrial systems and if so how. Also to analyze the complex behaviors that exists in the OSE kernel and to contribute with suggestions for improving the overall performance.