eration token availability check, etc. Move nonessential logic out of the critical path. All blocks of logic in the critical path should be evaluated to see if they could be performed elsewhere by a less critical resource. So, for example, if an application was maintaining statistics or table values in the critical path, it might be possible to offload this processing from the realtime path to a background operation that is not time critical. It might even be possible for the processor to push the relevant data up to the cloud and have processing be performed there. Avoid shared and global memory accesses. Shared accesses within a multicore environment take more clock cycles. Accessing memory by one core from the other core memory goes across the coherent interconnect within the SoC and can take 10 or 100 seconds extra clock cycles in the worst case. It can be more efficient to distribute data among cores (e.g., in statistics) and doing aggregation in a separate (background) process. Tune use of interrupts. In an realtime operating system but more so in high-level operating system such as Linux, interrupts incur a large overhead in saving and restoring context information. Instead, your application should not set up the interrupt vector for that event but could add a test in the normal code (polling mode operation) to handle the event or exception condition without interrupts. Tune table configurations. For example, always make sure that a hash table has at least two times the number of keys that will be active at any given time. If possible, reduce the amount of payload returned by any table lookup to fit in a small and sequential amount of cache lines. Avoid simultaneous requests for the same resource. The sequencing of events in most multicore processor applications will produce a random distribution of requests for Chapter 9 Software performance resources by the various cores in the processor. It can happen in some instances, however, that an application will tend to generate multiple, simultaneous requests t