On 11/08/2016 08:50 PM, Peter Zijlstra wrote: >> The problem is that using RT_RUNTIME_SHARE a CPU will almost always >> > borrow enough runtime to make a CPU intensive rt task to run forever... >> > well not forever, but until the system crash because a kworker starved >> > in this CPU. Kworkers are sched fair by design and users do not always >> > have a way to avoid them in an isolated CPU, for example. >> > >> > The user then can disable RT_RUNTIME_SHARE, but then the user will have >> > the CPU going idle for (period - runtime) at each period... throwing CPU >> > time in the trash. > So why is this a problem? You really should not be running that much > FIFO tasks to begin with. I agree that a spinning real-time task is not a good practice, but there are people using it and they have their own reasons/metrics/evaluations motivating them. > So I'm willing to take out (or at least default disable > RT_RUNTIME_SHARE). But other than this, this never really worked to > begin with. So it cannot be a regression. And we've lived this long with > the 'problem'. I agree! It would work perfectly in the absence of tasks pinned to a processor, but that is not the case. Trying to attend the users that want as much CPU time for -rt tasks as possible, the proposed patch seems to be a better solution when compared to RT_RUNTIME_SHARE, and it is way simpler! Even though it is not as perfect as a DL Server would be in the future, it seems to be useful until there... > We really should be doing the right thing here, not make a bigger mess. I see, agree and I am anxious to have it! :-). Tommaso and I discussed about DL servers implementing such rt throttling. The more complicated point so far (as Rostedt pointed on another e-mail) will be to have DL servers with arbitrary affinity, or serving task with arbitrary affinity. For example, one DL server pinned to each CPU providing bandwidth for fair tasks to run for (rt_period - rt_runtime)us at each rt_period... it will take sometime until someone propose it. -- 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
