Kernel tuning for VME messaging in a Closely Coupled Environment

An application running in non-blocking/fixed priority of (global) 100 or above can cause a degraded throughput or a kernel hang due to memory starvation. If an application is using any VME messaging or DMA, then the application is dependent upon services provided by the vmemsg and dmac daemons. These daemons MUST be allowed to run - or they will consume memory until the system becomes unusable.


The vmemsg and dmac daemons are interrupt daemons that are a vital part of networking over the VME interface. The default scheduling policy for these kernel daemons is SYSTEM class with a global priority of 99. This means that a program running in the FP class that is CPU-bound can starve these daemons if they are run at the default scheduling priorities.

To prevent the above situation from occurring the application must either; 

Block for a sufficient period of time to allow daemon processing to occur normally. OR
Application must run at a lower priority than the vmemsg and dmac daemons.
Choice number two can be achieved by raising daemon priorities to FP 59 and restricting application priorities to FP 58 and lower. Setting the following kernel tuneables will raise the daemon priorities:

DMAC_DAEMON_CLASS FP 

DMAC_DAEMON_PRI 59

VMEMSGD_CLASS FP 

VMEMSGD_PRI 59

Note: This problem can occur on the VME boot host as well as a target. Both kernels should be re-built.