linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: benh@kernel.crashing.org
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Sebastien Dugue <sebastien.dugue@bull.net>,
	Jan-Bernd Themann <ossthema@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Christoph Raisch <RAISCH@de.ibm.com>
Subject: Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Date: Wed, 24 Sep 2008 06:02:54 -0500	[thread overview]
Message-ID: <f30d1d832fd4ad096afccf198c14a7bb@bga.com> (raw)
In-Reply-To: <1222251467.8277.73.camel@pasglop>

On Sep 24, 2008, at 5:17 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
>> The per-interrupt mask and unmask calls have to go through RTAS, a
>> single-threaded global context, which in addition to increasing
>> path length will really limit scalability.  The interrupt controller
>> poll and reject facilities are accessed through hypervisor calls
>> which are comparable to a fast syscall, and parallel to all cpus.
>
> Note also that the XICS code thus assumes, iirc, as does the cell IIC
> code, that eoi is called on the -same- cpu that fetched the interrupt
> initially. That assumption can be broken with IRQ threads no ?

There may be some implicit assumption in that we expect the cpu 
priority to be returned to normal by the EOI, but there is nothing in 
the hardware that requires the EOI to come from the same cpu as 
accepted the interrupt for processing, with the exception of the IPI 
which is per-cpu (and the only interrupt that is per-cpu).

It would probably mean adding the concept of the current cpu priority 
vs interrupts and making sure we write it to hardware at irq_exit() 
time when deferring the actual irq handlers.

The MPIC hardware, on the other hand, maintains a queue of pending 
interrupts (It has been about a decade but the number 4-5 comes to 
mind), and the hardware must receive the EOI on the cpu that took it.  
I am guessing that the handling described (take level irq, mask it, eoi 
it, dispatch the thread, then unmask it after processing) is a result 
to work within those limitations.  Do you know the cell IIC to know if 
its mpic or xics in this regard?

The other unknown is the (very few) platforms that present as xics but 
are really firmware on mpic.  If they do a full virtual layer and don't 
take shortcuts but do eoi/mask like described here they should work, 
but I would not be surprised that does not hold true :-(.

milton

  reply	other threads:[~2008-09-24 11:02 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-15  8:04 [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption Sebastien Dugue
2008-09-15 12:17 ` Jan-Bernd Themann
2008-09-15 12:35 ` Thomas Klein
2008-09-15 13:13   ` Sebastien Dugue
2008-09-16 11:59     ` Anton Vorontsov
2008-09-16 12:22       ` Sebastien Dugue
2008-09-18  7:53 ` Christoph Raisch
2008-09-18  9:27   ` Sebastien Dugue
2008-09-18 10:42     ` [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption, eHCA is close Christoph Raisch
2008-09-18 12:31       ` Sebastien Dugue
2008-09-23 15:43         ` Jan-Bernd Themann
2008-09-24  9:58 ` [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption Milton Miller
2008-09-24 10:17   ` Benjamin Herrenschmidt
2008-09-24 11:02     ` Milton Miller [this message]
2008-09-24 21:14       ` Benjamin Herrenschmidt
2008-09-25  7:31         ` Sebastien Dugue
2008-09-24 12:35     ` Sebastien Dugue
2008-09-24 21:15       ` Benjamin Herrenschmidt
2008-09-25  7:18         ` Sebastien Dugue
2008-09-25  7:22           ` Benjamin Herrenschmidt
2008-09-25  7:42             ` Sebastien Dugue
2008-09-25  8:36               ` Benjamin Herrenschmidt
2008-09-25  8:39                 ` Sebastien Dugue
2008-09-24 12:30   ` Sebastien Dugue
2008-09-24 16:42     ` Milton Miller
2008-09-24 21:16       ` Benjamin Herrenschmidt
2008-09-25  3:56         ` Milton Miller
2008-09-25  8:45       ` Sebastien Dugue
  -- strict thread matches above, loose matches on Subject: below --
2008-09-25 23:40 Milton Miller
2008-09-26  9:16 ` Sebastien Dugue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f30d1d832fd4ad096afccf198c14a7bb@bga.com \
    --to=miltonm@bga.com \
    --cc=RAISCH@de.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=ossthema@de.ibm.com \
    --cc=paulus@samba.org \
    --cc=sebastien.dugue@bull.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).