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

[chensong <chensong_2000@189.cn>]

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
> 
>