On 12 Oct 2022 15:10:37 +0100 Qais Yousef <qais.yousef@xxxxxxx> > 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. Nope, see below. > That patch is to help describe some > latency requirements for CFS tasks. It has nothing to do with RT. Your Correct. > suggestion to use RT scheduler is not valid as these tasks can't be converted > to RT. My suggestion [2,3] to that patch is add a mild change to tick preempt. [2] https://lore.kernel.org/all/20221008103439.107-1-hdanton@xxxxxxxx/ [3] https://lore.kernel.org/all/20220920113238.1176-1-hdanton@xxxxxxxx/ > Which is what Steve was trying to say IIUC. No followup. > > 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? Thanks for good material. > > ie: using RT policy is a privileged operation for a reason :-) Take note. Hillf
