lkml.org 
[lkml]   [2021]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] kernel:irq:manage: request threaded irq with a specified priority
From
Date
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
>

\
 
 \ /
  Last update: 2021-04-18 16:41    [W:0.368 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site