Messages in this thread | | | Subject | Re: [PATCH] kernel:irq:manage: request threaded irq with a specified priority | From | chensong <> | Date | Sun, 18 Apr 2021 22:33:52 +0800 |
| |
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 >
| |