Re: [PATCH v2 1/3] cobalt: Prepare for new signature of __request_percpu_irq() in 6.19

Philippe Gerum <[email protected]> writes:

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

In fact, no tick can ever happen on cpus out of the oob set precisely
because no proxy is installed for those.

-- 
Philippe.