On 11/07/2016 07:30 PM, Steven Rostedt wrote: >> I'm still reviewing the patch, but I have to wonder why bother with making it a scheduler feature? >> > >> > The SCHED_FIFO definition allows a fifo thread to starve others >> > because a fifo task will run until it yields. Throttling was added as >> > a safety valve to allow starved SCHED_OTHER tasks to get some cpu >> > time. Adding this unconditionally gets us a safety valve for >> > throttling a badly written fifo task, but allows the fifo task to >> > continue to consume cpu cycles if it's not starving anyone. >> > >> > Or am I missing something that's blazingly obvious? > Or I say make it the default. If people want the old behavior, they can > modify SCHED_FEATURES to do so. I added it as a feature to keep the current behavior by default. Currently, we have two throttling modes: With RT_RUNTIME_SHARING (default): before throttle, try to borrow some runtime from other CPU. Without RT_RUNTIME_SHARING: throttle the RT task, even if there is nothing else to do. The problem of the first is that an CPU easily borrow enough runtime to make the spin-rt-task to run forever, allowing the starvation of the non-rt-tasks, hence invalidating the mechanism. The problem of the second is that (with the default values) the CPU will be idle 5% of the time. IMHO, the balanced behavior is using GREED option + without RT_RUNTIME_SHARING: the non-rt tasks will be able to run, while avoiding CPU going idle. We can turn it by default setting default options. Moreover, AFAICS, these sched options are static keys, so they are very very low overhead conditions. -- Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
