Full load occurs when all partitions demand their full budget. A simple way to demonstrate this is to run while(1) loops in all of the sample partitions. In this case, the aps show command might display:
+-------- CPU Time -------+-- Critical Time --
Partition name id | Budget | Max | Used | Budget | Used
--------------------+-------------------------+-------------------
System 0 | 70% | 100% | 69.80% | 200ms | 0.000ms
Pa 1 | 20% | 100% | 19.99% | 0ms | 0.000ms
Pb 2 | 10% | 100% | 9.81% | 0ms | 0.000ms
--------------------+-------------------------+-------------------
Total | 100% | | 99.61% |
In this example, the requirement to meet the partitions' guaranteed budgets takes precedence over priority.
In general, when partitions are at or over their budget, the thread scheduler divides time between them by the ratios of their budgets, and balances usage to a few percentage points of the partitions' budgets. (For more information on budget accuracy, see “Choosing the window size” in the Considerations for Scheduling chapter of this guide.)
Even at full load, the thread scheduler can provide realtime latencies to an engineerable set of critical threads (see “Critical threads” later in this chapter). However, in that case, the scheduling of critical threads takes precedence over meeting budgets.
Figure 1. The thread scheduler's behavior under a full load.