On 10/11/22 19:18, Hillf Danton wrote: [...] > > The issue at hand here is that the softirqs boundedness is hard to control. And > > the scheduling delays ensued are hard to deal with by any sys-admin. > > > Given "The RT scheduler is for tasks that require strick scheduling > requirements over all else, including performance." [1], I would invite > Steve to shed some more light on the relation between RT scheduler and > performance/network throughputs. > > Bonus question, why softirq took no care of RT tasks, given strick > scheduling requirements above? > > [1] https://lore.kernel.org/lkml/257E96C2-6ABD-4DD6-9B7F-771DA3D1BAAA@xxxxxxxxxxx/ I think you're mixing the two patches up. That patch is to help describe some latency requirements for CFS tasks. It has nothing to do with RT. Your suggestion to use RT scheduler is not valid as these tasks can't be converted to RT. Which is what Steve was trying to say IIUC. Generally converting normal application tasks into RT is a recipe for disaster because: 1. Misbehaving RT tasks (busy looping indefinitely) can hog the system to a halt. 2. How do you manage priorities of all these pseudo-random RT tasks each application spawns so you end up with correct resource sharing? ie: using RT policy is a privileged operation for a reason :-) The target audience for latency_nice is the average Joe task from any application that might have some latency requirements to deliver a better user experience. ie: it's not strict latency requirement. We just want to handle delays within _CFS_ part of the scheduler. By the way, your emails don't seem to make it to LKML for some reason; they show as '[not found]' on lore. https://lore.kernel.org/lkml/20221010154216.6mw7fszdaoajurvm@wubuntu/#r Thanks -- Qais Yousef
