On 11/08/2016 07:05 PM, Peter Zijlstra wrote: >> > >> > I know what we want to do, but there's some momentous problems that >> > need to be solved first. > Like what? 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. >> > Until then, we may be forced to continue with >> > hacks. > Well, the more ill specified hacks we put in, the harder if will be to > replace because people will end up depending on it. The proposed patch seems to be the expected behavior for users/rt throttling - they want a safeguard for fair tasks while allowing -rt tasks to run as much as possible. I see (and completely agree) that a DL server for fair/rt task would be the best way to deal with this problem, but it will take some time until such solution :-(. We even discussed this at Retis today, but yeah, it will take sometime even in the best case. (thinking aloud... a DL Server would react like the proposed patch, in the sense that it would not be activated without tasks to run and would return the CPU for other tasks if the tasks inside the server finish their job before the end of the DL server runtime...) -- 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
