Re: [PATCH] kernel:irq:manage: request threaded irq with a specified priority

[chensong]

Daniel & tglx,

Points taken and thanks a lot for such detailed explanations.

BR

Song

On 2021/4/16 下午5:09, Thomas Gleixner wrote:
> On Fri, Apr 16 2021 at 12:57, chensong wrote:
> > On 2021/4/13 下午4:39, Thomas Gleixner wrote:
> > > It breaks because the system designer failed to assign proper priorities
> > > to the irq threads int_a, int_b and to the user space process task_a.
> >
> > yes, it's designers' responsibility to assign proper priorities, but
> > kernel is also obliged to provide interfaces for those designers.
>
> The interface exists. sched_setscheduler(2)
>
> > chrt can help designers in this case, however, the truth is lot of
> > customers are not familiar with it.
>
> The truth is that real-time systems need to be carefully designed and
> parametrized. And that's only possible when _all_ of the system
> components and their constraints are known. Trying to solve it at the
> device driver level of a single device is impossible and a guarantee for
> fail.
>
> If the customer does not know how to do it, then I really have to ask
> why he's trying to use a real-time system at all. There is no real-time
> system which magically tunes itself by pulling the overall system
> constraints out of thin air.
>   
> > what's more, chrt can also apply to userspace rt task, but userspace
> > also has sched_setscheduler to assgin proper priority inside code like
> > cyclictest, why can't driver writers have another choice?
>
> There is a very simple reason: The driver writer cannot know about the
> requirements of the complete system which is composed of kernel, drivers
> and user space applications, unless the driver writer is fully aware of
> the overall system design and constraints.
>
> How is that supposed to work on a general purpose kernel which is
> utilized for a gazillion of different use cases which all have different
> expectations?
>
> It simply cannot work because default A will only work for usecase A and
> be completely wrong for all others.
>
> > Further, what if irq handlear thread has to run on the expected priority
> > at the very beginning? This patch helps.
>
> There is no such thing as the expected priority of an interrupt thread
> which can be applied upfront.
>
> There are ~5400 instances of request*irq() in the kernel source and
> there is no way to make priority decisions for them which work for every
> RT system out there.
>
> The kernel sets a default and the system designer, admin, user has to
> take care of tuning it to match the expectations and constraints of his
> particular application scenario.
>
> The kernel provides an userspace interface to do that. That interface
> might be a bit awkward to use, but there are tools out there which help
> with that, and if at all we can think about providing a better and
> easier to use interface for this.
>
> Trying to solve that at the kernel level is putting the cart before the
> horse.
>
> Thanks,
>
>          tglx