Re: [PATCH v2 1/3] cobalt: Prepare for new signature of __request_percpu_irq() in 6.19
Philippe Gerum <[email protected]>
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <[email protected]> |
Jan Kiszka <[email protected]> writes: > On 25.02.26 17:43, Philippe Gerum wrote: >> Jan Kiszka <[email protected]> writes: >> >>> On 24.02.26 22:11, Jan Kiszka wrote: >>>> On 20.02.26 12:27, Florian Bezdeka wrote: >>>>> The signature of __request_percpu_irq() got one additional affinity >>>>> parameter in 6.19 and 7.0 will remove the function entirely. >>>>> >>>>> Dovetail 6.19 will introduce a new dovetail specific service called >>>>> request_percpu_irq_affinity_flags() that allows us to set flags and >>>>> affinity at the same time. >>>>> >>>>> It might happen that older Dovetail versions get the new API via >>>>> backports, so the re-#definement for older kernels might get >>>>> obsolete earlier than dropping support for Dovetail < 6.19. >>>>> >>>>> Signed-off-by: Florian Bezdeka <[email protected]> >>>>> --- >>>>> include/cobalt/kernel/dovetail/pipeline/irq.h | 6 ++++++ >>>>> include/cobalt/kernel/dovetail/pipeline/pipeline.h | 9 ++++----- >>>>> include/cobalt/kernel/dovetail/pipeline/sirq.h | 9 ++++----- >>>>> kernel/cobalt/dovetail/tick.c | 8 ++++---- >>>>> 4 files changed, 18 insertions(+), 14 deletions(-) >>>>> >>>>> diff --git a/include/cobalt/kernel/dovetail/pipeline/irq.h b/include/cobalt/kernel/dovetail/pipeline/irq.h >>>>> index 55d9b8ff17cd08e5e8c09aec393a1e23736c1b76..df0b8ceb05c25d655a331d238e7ef8ac8a6afeea 100644 >>>>> --- a/include/cobalt/kernel/dovetail/pipeline/irq.h >>>>> +++ b/include/cobalt/kernel/dovetail/pipeline/irq.h >>>>> @@ -5,6 +5,12 @@ >>>>> #ifndef _COBALT_KERNEL_DOVETAIL_IRQ_H >>>>> #define _COBALT_KERNEL_DOVETAIL_IRQ_H >>>>> >>>>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 19, 0) >>>>> +#define request_percpu_irq_affinity_flags(irq, handler, flags, devname, \ >>>>> + affinity, dev_id) \ >>>>> + __request_percpu_irq(irq, handler, flags, devname, dev_id) >>>> >>>> BTW, this effectively invalidates the affinity parameter. Before we >>>> could make use of it, we would have to backport the dovetail function to >>>> older kernels as well (6.1 right now). >>>> >>> >>> For the time being, I would like to have a WARN_ON_ONCE(affinity != >>> NULL) in the wrapper so that we have a chance to detect future overuse >>> of the new API. >>> >>>> At the same time, we seem to be forced to create all the OOB interrupts >>>> on all the cores anyway, even when supported_cpus is set to a smaller >>>> set. I do not recall why that is the case, I just vaguely remember >>>> having asked this before. And as long as it is required, the new >>>> affinity parameter will remain NULL. >>> >>> Would still be interesting to recap this aspect, both for classic cobalt >>> (supported_cpus) but also the evl core (oobcpus). Even if the lock >>> contention in the absence of a global nklock is not there anymore, I >>> guess there would be value in not having to proxy the timer on cores >>> that do not host RT workload. But evl is currently requesting the proxy >>> for all cpus as well, isn't it? >> >> Only on the evl_oob_cpus set (tick_install_proxy()). >> > > But per-cpu interrupts are requested for all cores, no? > Yes, but no tick events should be flowing on the non-oob cores since there is no _active_ runqueue on those (although all runqueues are initialized to recover from user misconfiguration of process affinity). IOW, the evl core can and will use request_percpu_irq_affinity_flags() when available. -- Philippe.