Date:   Sun, 18 Apr 2021 22:33:52 +0800
From:   chensong <chensong_2000@....cn>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, mingo@...hat.com, peterz@...radead.org,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, keescook@...omium.org,
        gregkh@...uxfoundation.org, maz@...nel.org, joe@...ches.com,
        romain.perier@...il.com, john.garry@...wei.com
Subject: Re: [PATCH] kernel:irq:manage: request threaded irq with a specified
 priority

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
> 

Powered by blists - more mailing lists