If you use adaptive partitions, you need to be aware of the following limitations:
-
The API allows a window size as short as 8 milliseconds,
but practical window sizes may need to be larger.
For example, in an eight-partition system, with all partitions busy,
to reasonably expect all eight to run during every window, the
window size needs to be at least 8 timeslices long,
which for most systems is 32 milliseconds.
- Overloads aren't reported to users.
The Adaptive Partition scheduler does detect
overload and acts to limit some partitions to guarantee the percentage shares of others,
but it doesn't inform anything outside of the kernel that an overload was detected.
The problem is that an overload might occur (or might not occur) on every scheduling
operation, which can occur thousands of time per second.
- SCHED_RR threads might not round-robin in partitions whose portion of the
averaging window is smaller than one timeslice. For example, when the timeslice is 4 ms (the
default) and the adaptive partitioning scheduler's window size is 100 ms (the default), then
SCHED_RR threads in a 4% partition may not round-robin correctly.
- If you use adaptive partitioning and bound multiprocessing (BMP), some combinations of
budgets might not be met. Threads in a zero-budget partition should run
only when all other nonzero-budget partitions are idle.
On SMP machines, zero-budget partitions may incorrectly run when some other partitions are
demanding time.
At all times, all partitions' minimum budgets are still guaranteed,
and zero-budget partitions won't run if all nonzero-budget partitions are ready to run.
For detailed information, see
“Using the thread scheduler and multicore together”
in the Using the Thread Scheduler chapter.