Re: [RFC PATCH v4 2/3] sched: Avoid placing RT threads on cores handling long softirqs

[Hillf Danton <hdanton@sina.com>]

On 12 Oct 2022 15:10:37 +0100 Qais Yousef <qais.yousef@arm.com>
> 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@goodmis.org/
> 
> 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@sina.com/
[3] https://lore.kernel.org/all/20220920113238.1176-1-hdanton@sina.com/

> 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