[Xenomai-core] Re: How to hook genirq best

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4317 bytes --]

Philippe Gerum wrote:
> On Wed, 2006-12-06 at 13:05 +0100, Jan Kiszka wrote:
>> Philippe Gerum wrote:
> 
> [...]
> 
>>> The other important issue is that patching the call sites does not
>>> preclude from analysing each and every PIC control routine, for ironing
>>> them. When the number of PICs is small enough, it's clearly safer to
>>> have all changes at one location (i.e. the PIC management file). At
>>> least, you know what has been adapted; but it's (only) a matter of
>>> (maintainer's) taste.
>> Having a look at new/updated PIC code is one (unavoidable) thing,
>> actually having to touch it and keeping the changes in sync even with
>> only minor style changes or the code is another.
>>
> 
> It's not a problem to fix minor style changes in arch-dep code; but it
> can be very annoying to forget important changes in generic the code. So
> your argument cuts both ways. Really, it's a matter of where one thinks
> the code is going to change in the most significant way. Regarding x86
> (and I'm not arguing for any other arch, here), I see less changes to
> happen in the PIC-dependent routines, than at their call sites, as more
> archs are being converted to use the genirq layer. In any case, I don't
> see this issue as being critical; it would be easy to change the
> implementation overnight without any drawback imposed on client code.

Ok, let's see how other archs work this out and then decide how to
consolidate the solutions. I would just try to find a common way, also
to make understanding the patch mechanisms easier (for future ports).

> 
> [...]
> 
>>> --- arch/i386/kernel/ipipe.c~	2006-12-03 18:12:59.000000000 +0100
>>> +++ arch/i386/kernel/ipipe.c	2006-12-06 12:36:21.000000000 +0100
>>> @@ -167,10 +167,12 @@
>>>  static int __ipipe_ack_irq(unsigned irq)
>>>  {
>>>  	irq_desc_t *desc = irq_desc + irq;
>>> +
>>> +	desc->chip->ipipe_ack(irq);
>>> +
>> Might be NULL for some chips like fasteoi ones, no?
>>
> 
> Not for x86, ipipe_ack is always valid, and __ipipe_ack_irq() which
> calls it is arch-dependent, so we are safe. Controlling the irq_chip

lapic_chip?

Moreover, calling [ipipe_]ack is flow type specific. So you would also
have to install a no-op handler for fasteoi chips e.g. Given that
ioapic_chip seems to be used for both edge-triggered and fast irqs, your
previous version looks better.

> descriptor, instead of generalizing the logic from the generic code
> (which could not have told you that), is an advantage here.
> 
>>>  	if (desc->handle_irq == &handle_fasteoi_irq)
>>>  		desc->chip->ipipe_eoi(irq);
>>> -	else
>>> -		desc->chip->ipipe_ack(irq);
>>> +
>>>  	return 1;
>>>  }
>>>  
>>> This is not relevant to the way we hook genirq though; we need to handle
>>> this in the primary I-pipe handler anyway.
>>>
>>>>  Generally, the question remains for me
>>>> if at least IRQs arriving to a stalled I-pipe domain should always be
>>>> masked on ack and unmask when being replayed.
>>> What particular (problematic) case do you have in mind regarding this?
>> Recurring IRQs of the same source to a stalled domain, potentially
>> disturbing a higher prio domain (even if they do not get beyond I-pipe
>> core stubs). -rt has to deal with the same issue for low-prio threaded
>> IRQs, and I don't see a reason yet why we should differ when they keep
>> the line masked after the first or the second event.
>>
> 
> This problem should be addressed at a higher level: how do we prevent
> low-priority IRQs from ever happening when a high priority domain is
> running, so that such IRQs could not even hit the primary Adeos handler.
> Currently, the pipeline head optimization avoids such perturbation when
> the high priority domain is stalled by masking the interrupts at CPU
> level; what we need is to extend this to the unstalled state.

Yep.

> 
> This issue goes beyond the quick hack of masking recurring IRQs, and
> IIRC, we discussed it briefly on this list some months ago. This is what
> would bring a significant improvement wrt determinism.

As long as we do not fall back behind previous characteristics of
I-pipe, I see no problem with addressing this in an even smarter way
later. Is this patch equivalent, e.g. to 1.5's behaviour?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]