Practical limits

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.