From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <50576A79.70003@xenomai.org> Date: Mon, 17 Sep 2012 20:22:49 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <5056C385.6090403@xenomai.org> <5056D4AE.2010201@web.de> <5056DA52.6040006@xenomai.org> <5056DCC5.10909@web.de> <5056E024.5020904@xenomai.org> <5056E863.4090606@siemens.com> <5056ED68.6050101@xenomai.org> <5056F09C.8050602@siemens.com> <5056F4A1.6070500@xenomai.org> <50570606.7060909@xenomai.org> <5057173C.9070108@siemens.com> <5057299B.9060804@xenomai.org> <50572B95.2060302@siemens.com> <50572D86.3040306@xenomai.org> <50573532.20700@siemens.com> <505761DF.3010609@xenomai.org> <5057666D.7080404@siemens.com> <50576725.9030601@xenomai.org> <50576804.9030109@siemens.com> <505768B9.6000704@siemens.com> <50576970.6010306@xenomai.org> In-Reply-To: <50576970.6010306@xenomai.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] IO-APIC latencies List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Xenomai On 09/17/2012 08:18 PM, Gilles Chanteperdrix wrote: > On 09/17/2012 08:15 PM, Jan Kiszka wrote: > >> On 2012-09-17 20:12, Jan Kiszka wrote: >>> On 2012-09-17 20:08, Gilles Chanteperdrix wrote: >>>> On 09/17/2012 08:05 PM, Jan Kiszka wrote: >>>> >>>>> On 2012-09-17 19:46, Gilles Chanteperdrix wrote: >>>>>> ipipe_end is a nop when called from primary domain, yes, but this is not >>>>>> very different from edge irqs. Also, fasteoi become a bit like MSI: in >>>>>> the same way as we can not mask MSI from primary domain, we should not >>>>>> mask IO-APIC fasteoi irqs, because the cost is too prohibitive. If we >>>>>> can live with MSI without masking them in primary mode, I guess we can >>>>>> do the same with fasteoi irqs. >>>>> >>>>> MSIs are edge triggered, fasteois are still level-based. They require >>>>> masking at the point you defer them - what we do and what Linux may even >>>>> extend beyond that. If you mask them by raising the task priority, you >>>>> have to keep it raised until Linux finally handled the IRQ. >>>> >>>> >>>> Yes. >>>> >>>>> Or you >>>>> decide to mask it at IO-APIC level again. >>>> >>>> >>>> We do not want that. >>>> >>>>> If you keep the TPR raised, >>>>> you will block more than what Linux wants to block. >>>> >>>> >>>> The point is that if the TPR keeps raised, it means that primary domain >>>> has preempted Linux, so, we want it to keep that way. Otherwise the TPR >>>> gets lowered when Linux has handled the interrupt. >>>> >>>> A week-end of testing made me sure of one thing: it works. I assure you. >>> >>> Probably, in the absence of IRQF_ONESHOT Linux interrupts. No longer if >>> you face threaded IRQs - I assure you. >> >> Well, it may work (if mask/unmask callbacks work as native) but the >> benefit is gone: masking at IO-APIC level will be done again. Given that >> threaded IRQs become increasingly popular, it will also be hard to avoid >> them in common setups. > > > The thing is, if we no longer use the IO-APIC spinlock from primary > domain, we may not have to turn it into an ipipe_spinlock, and may be > able to preempt the IO-APIC masking. > No, we need it in ack_apic_level in the IO-APIC erratum case. -- Gilles.