Performance Guarantee Tutorial

Describes how to maintain performance guarantees when writing a software package on a data paged platform.

• Perform a static analysis of the impact of data paging on your code.
  1. 
     List all the executables in your package, indicating their size and pageability.
  2. 
     For each item in the list identify its static dependencies, indicating their size and pageability.
  3. 
     For each item in the list identify its dynamic dependencies, indicating their size and pageability. For instance, note whether the component is a plug-in to a framework or is itself a framework.
  The purpose of collecting this information is to identify which executables are most likely to be impacted by data paging.
• Perform a use case analysis of the impact of data paging on your code. It is good practice to distinguish between use cases involving real time and performance critical performance guarantees. You do not need to cover use cases which do not involve guarantees of this kind.
  1. List all the use cases for the component which involve real time performance guarantees. Real time use cases are those having very strict response time guarantees and also those involving an acceptable user perception of behaviour.

     • Video playback,

     • VoIP phone calls, and

     • File download over USB.

     Examples of use cases involving acceptable user perception are:
  2. List all the use cases for the component which involve performance critical guarantees. This means the bench-marked use cases by which the performance of the operating system is measure. Examples of use cases having a strict response time are:

     • Standard boot time,

     • Application start-up time, and

     • Camera image capture time.

  3. Identify compound cases involving both real time and performance critical guarantees. An example of a compound case is receiving a text message while playing MP3 audio.
• Perform an IPC analysis of the impact of data paging on your code.
  1. Identify all performance critical or real time servers which the component interacts with.
  2. List each case where these servers read paged data from a client's address space. In this case, paged data includes:

     • Paged heaps and stacks,

     • RAM-loaded code, and

     • Read only XIP data structures including

       • bitmaps,

       • constant descriptors,

       • constant data arrays in code,

       • data files accessed through a pointer, and

       • exported DLL data.

  3. Identify all cases of custom architectures where one thread reads from another thread's address space.
• Take steps to mitigate the impacts of data paging which you have identified, as appropriate to each case.
  1. Protect the real time and performance critical code paths. These paths will have been identified in the static analysis of the component. There are two ways of protecting them.

     • For all use cases, ensure that the minimum paging cache size is large enough to accommodate both the protected code path and any other paged data required at the same time.

       This method of protection may not always be practical, because compound use cases may involve unpredictable amounts of data which exceed the size of the paging cache.

     • Make the protected code path unpaged. Mark the code itself as unpaged, and either mark whole regions of memory as unpaged or pin memory to ensure that it is unpaged.

  2. Redesign the component architecture to isolate areas where data paging impacts on performance. Examples of this are:

     • Separating the data plane and the control plane, and

     • Splitting a monolithic library into paged and unpaged parts.

  3. Use code paging or XIP ROM paging to mitigate the impact of paging. For instance, a monolithic library with static dependences may only need to be partially loaded, and some dependencies may not need to be loaded at all.
  4. 
     Mitigate the impact of data paging on IPC using the techniques set out in the document Device Driver Writing Technology Tutorial