Clarification about IRQ terminology

Clarification about IRQ terminology

[Joel Fernandes]

Hi,

Recently had a discussion with a colleague about hard vs soft irqs. We
also discussed process vs interrupt context and I had some confusion
about when to (and when not to use) the terms hard irq handler.

Just to clarify and use the right terminology, I'd like to understand
whether the "hard" in hard irq implies interrupt context?

To further confuse the matter, with CONFIG_PREEMPT_RT_FULL, all IRQs
previously executing in interrupt context are now threaded. Then in
this scenario, is it Ok to still call these irq handlers as hard irq
handlers or should they now be strictly called threaded interrupt
handlers now that the same handlers are forced to execute in a thread?
If the "hard" in hard irq means hardware interrupt, then it would make
sense to still call them hardirq handlers even though they're now
executing in process context?

So basically my questions are:
1. Does hard in hard irq mean hardware interrupt or does it imply
interrupt context?
2. Can the terms "hard irq handler" still be used with CONFIG_PREEMPT_RT_FULL?

Thanks a lot,

Joel

Re: Clarification about IRQ terminology

[Sebastian Andrzej Siewior]

On 2016-10-05 23:07:55 [-0700], Joel Fernandes wrote:
> Just to clarify and use the right terminology, I'd like to understand
> whether the "hard" in hard irq implies interrupt context?
it usually does.

> To further confuse the matter, with CONFIG_PREEMPT_RT_FULL, all IRQs
> previously executing in interrupt context are now threaded. Then in

not all but most. And also in !RT with the threadirqs command line
argument.

> this scenario, is it Ok to still call these irq handlers as hard irq
> handlers or should they now be strictly called threaded interrupt
> handlers now that the same handlers are forced to execute in a thread?

If they are threaded, they are threaded. A threaded handler can be
interrupted by an interrupt because it is invoked with interrupts
enabled. A non-threaded handler can not be interrupted.

> If the "hard" in hard irq means hardware interrupt, then it would make
> sense to still call them hardirq handlers even though they're now
> executing in process context?

you call them interrupt handler. You can request *explicit* a threaded
handler if your code needs to sleep (in order to reach hardware behind a
slow bus like i2c).

> So basically my questions are:
> 1. Does hard in hard irq mean hardware interrupt or does it imply
> interrupt context?

I would drop that hard part. It is an interrupt handler. It then can be
either threaded or not and it can be always threaded or sometimes.
hard is used to distinguish this kind of interrupts from the soft-irqs.

> 2. Can the terms "hard irq handler" still be used with CONFIG_PREEMPT_RT_FULL?

not all interrupts are threaded. perf and timer are just two examples of
interrupts which are never threaded. So some interrupts are handled with
interrupts disabled and some with interrupts enabled.

> Thanks a lot,
> 
> Joel

Sebastian

Re: Clarification about IRQ terminology

[Joel Fernandes]

Hi Sebastian,

Thanks a lot for your quick reply. I agree with all your points, I had
a comment about one of them:

> > So basically my questions are:
> > 1. Does hard in hard irq mean hardware interrupt or does it imply
> > interrupt context?
>
> I would drop that hard part. It is an interrupt handler. It then can be
> either threaded or not and it can be always threaded or sometimes.
> hard is used to distinguish this kind of interrupts from the soft-irqs.
>

But with threaded interrupts, you do have a handler that wakes up the
thread. In this case there are 2 handlers, one handler executes in
interrupt context and wakes up the thread, and the other runs in the
thread. In this case, the term "interrupt handler" is confusing since
it isn't clear which handler we're referring to. "hard interrupt
handler" is also confusing - since if hard means "hardware", then
technically the thread is also a "hard interrupt handler" since the
interrupt line is masked (forced threaded interrupts are also one
shot) till the thread clears the interrupt reason.

Thanks,
Joel

Re: Clarification about IRQ terminology

[Sebastian Andrzej Siewior]

On 2016-10-06 20:15:16 [-0700], Joel Fernandes wrote:
> Hi Sebastian,
Hi Joel,

> > > So basically my questions are:
> > > 1. Does hard in hard irq mean hardware interrupt or does it imply
> > > interrupt context?
> >
> > I would drop that hard part. It is an interrupt handler. It then can be
> > either threaded or not and it can be always threaded or sometimes.
> > hard is used to distinguish this kind of interrupts from the soft-irqs.
> >
> 
> But with threaded interrupts, you do have a handler that wakes up the
> thread. In this case there are 2 handlers, one handler executes in
> interrupt context and wakes up the thread, and the other runs in the
> thread. In this case, the term "interrupt handler" is confusing since
> it isn't clear which handler we're referring to. "hard interrupt
> handler" is also confusing - since if hard means "hardware", then
> technically the thread is also a "hard interrupt handler" since the
> interrupt line is masked (forced threaded interrupts are also one
> shot) till the thread clears the interrupt reason.

so what is your point? You still have a primary handler and a secondary
/ threaded handler.
In -RT (!RT, too but I am not 100% sure) we can have three. Now I leave
it to your research to figure out when this might happen :)

> Thanks,
> Joel

Sebastian

Re: Clarification about IRQ terminology

[Joel Fernandes]

On Fri, Oct 7, 2016 at 3:32 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2016-10-06 20:15:16 [-0700], Joel Fernandes wrote:
>> Hi Sebastian,
> Hi Joel,
>
>> > > So basically my questions are:
>> > > 1. Does hard in hard irq mean hardware interrupt or does it imply
>> > > interrupt context?
>> >
>> > I would drop that hard part. It is an interrupt handler. It then can be
>> > either threaded or not and it can be always threaded or sometimes.
>> > hard is used to distinguish this kind of interrupts from the soft-irqs.
>> >
>>
>> But with threaded interrupts, you do have a handler that wakes up the
>> thread. In this case there are 2 handlers, one handler executes in
>> interrupt context and wakes up the thread, and the other runs in the
>> thread. In this case, the term "interrupt handler" is confusing since
>> it isn't clear which handler we're referring to. "hard interrupt
>> handler" is also confusing - since if hard means "hardware", then
>> technically the thread is also a "hard interrupt handler" since the
>> interrupt line is masked (forced threaded interrupts are also one
>> shot) till the thread clears the interrupt reason.
>
> so what is your point? You still have a primary handler and a secondary
> / threaded handler.

My point is its hard (no pun intended) to find a set of terms to
describe a handler to clearly define its context (interrupt vs process
context). I see "hard IRQ handler" mentioned in different
documentation referring to interrupt context but as we discussed this
isn't the case.

Thanks for referring to primary and secondary, I will use these to
differentiate between the 2 handlers. :)

> In -RT (!RT, too but I am not 100% sure) we can have three. Now I leave
> it to your research to figure out when this might happen :)
>

I guess primary and secondary also don't accurately describe context
anymore because of force threading of primary handlers [1] (which I
think is what you meant about having 3 handlers? :)) so I will just be
explicit about the context if I need to mention it in conversation. So
like "threaded primary handler".

Thanks,
Joel

[1] https://lkml.org/lkml/2015/9/21/124