Setting budgets to zero

It's possible to set the budget of a partition to zero as long as the SCHED_APS_SEC_NONZERO_BUDGETS security flag isn't set—see the SCHED_APS_ADD_SECURITY command for SchedCtl().

Threads in a zero-budget partition run only in these cases:

  • You're using the default scheduling policy (SCHED_APS_SCHEDPOL_DEFAULT), and the highest-priority thread in the system belongs to the zero-budget partition.
  • You're using SCHED_APS_SCHEDPOL_FREETIME_BY_RATIO, and all other nonzero-budget partitions are idle.
  • The zero-budget partition has a nonzero critical budget, in which case its critical threads run.
  • A thread receives a message from a partition with a nonzero budget, in which case the receiving thread runs temporarily in the sender's partition.

When is it useful to set the budget of a partition to zero?

It useful to set the budget of a partition to zero when:

  • A partition is permanently empty of running threads; you can set its budget to zero to effectively turn it off. When a zero-budget partition is idle, it isn't considered to produce free time (see Summary of scheduling behavior in the Using the Thread Scheduler chapter of this guide). A partition with a nonzero budget that never runs threads puts the thread scheduler permanently in free-time mode, which may not be the desired behavior.
  • You want noncritical code to run only when some other partition is idle.
  • The partition is populated by resource managers, or other software, that runs only in response to receiving messages. Putting them in a zero-budget partition means you don't have to separately engineer a partition budget for them. (Those resource managers automatically bill their time to the partitions of their clients.)
Note:
Typically, setting a partition's budget to zero is not recommended. (This is why the SCHED_APS_SEC_RECOMMENDED security setting doesn't permit partition budgets to be zero.) The main risk in placing code into a zero-budget partition is that it may run in response to a pulse or event (i.e., not a message), and therefore, not run in the sender's partition. As a result, when the system is loaded (i.e., there's no free time), those threads may simply not run; they might hang, or things might occur in the wrong order.

For example, it's hazardous to set the System partition's budget to zero. On a loaded machine with a System partition of zero, requests to procnto to create processes and threads may hang, for example, when MAP_LAZY is used. In addition, if your system uses zero-budget partitions, you should carefully test it with all other partitions fully loaded with while(1) loops.

Page updated: