lkml.org 
[lkml]   [2021]   [Apr]   [16]   [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


On 2021/4/13 下午4:39, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 14:19, Song Chen wrote:
>> In general, irq handler thread will be assigned a default priority which
>> is MAX_RT_PRIO/2, as a result, no one can preempt others.
>>
>> Here is the case I found in a real project, an interrupt int_a is
>> coming, wakes up its handler handler_a and handler_a wakes up a
>> userspace RT process task_a.
>>
>> However, if another irq handler handler_b which has nothing to do
>> with any RT tasks is running when int_a is coming, handler_a can't
>> preempt handler_b, as a result, task_a can't be waken up immediately
>> as expected until handler_b gives up cpu voluntarily. In this case,
>> determinism breaks.
>
> 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.

chrt can help designers in this case, however, the truth is lot of
customers are not familiar with it. 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?

Further, what if irq handlear thread has to run on the expected priority
at the very beginning? This patch helps.

BR

Song

>
> That's not solvable at the kernel level.
>
> Thanks,
>
> tglx
>
>

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