From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sebastien Dugue <sebastien.dugue@bull.net>
Cc: linux-kernel@vger.kernel.org, Milton Miller <miltonm@bga.com>,
linuxppc-dev@ozlabs.org, Christoph Raisch <RAISCH@de.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Jan-Bernd Themann <ossthema@de.ibm.com>
Subject: Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Date: Thu, 25 Sep 2008 07:15:17 +1000 [thread overview]
Message-ID: <1222290917.8277.83.camel@pasglop> (raw)
In-Reply-To: <20080924143552.29a14f10@bull.net>
On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
> Hi Ben,
>
> On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 ?
>
> No, the fetch and the eoi are both done in interrupt context before
> the hardirq thread is woken up.
>
> On the other hand, the mask+eoi and the unmask may well happen
> on different cpus as there's only one hardirq thread per irq on
> the system. Don't know if this is a problem with the XICS though.
Ok, that's the right approach then. It should work. I don't know what
the specific problems with HEA are at this stage. It doesn't seem to
make sense to implement a set_irq_type(), what would it do ? The
XICS doesn't expose any concept of interrupt type...
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sebastien Dugue <sebastien.dugue@bull.net>
Cc: Milton Miller <miltonm@bga.com>,
Jan-Bernd Themann <ossthema@de.ibm.com>,
Christoph Raisch <RAISCH@de.ibm.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Date: Thu, 25 Sep 2008 07:15:17 +1000 [thread overview]
Message-ID: <1222290917.8277.83.camel@pasglop> (raw)
In-Reply-To: <20080924143552.29a14f10@bull.net>
On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
> Hi Ben,
>
> On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 ?
>
> No, the fetch and the eoi are both done in interrupt context before
> the hardirq thread is woken up.
>
> On the other hand, the mask+eoi and the unmask may well happen
> on different cpus as there's only one hardirq thread per irq on
> the system. Don't know if this is a problem with the XICS though.
Ok, that's the right approach then. It should work. I don't know what
the specific problems with HEA are at this stage. It doesn't seem to
make sense to implement a set_irq_type(), what would it do ? The
XICS doesn't expose any concept of interrupt type...
Ben.
next prev parent reply other threads:[~2008-09-24 21:17 UTC|newest]
Thread overview: 60+ 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 8:04 ` Sebastien Dugue
2008-09-15 12:17 ` Jan-Bernd Themann
2008-09-15 12:17 ` Jan-Bernd Themann
2008-09-15 12:35 ` Thomas Klein
2008-09-15 12:35 ` Thomas Klein
2008-09-15 13:13 ` Sebastien Dugue
2008-09-15 13:13 ` Sebastien Dugue
2008-09-16 11:59 ` Anton Vorontsov
2008-09-16 11:59 ` Anton Vorontsov
2008-09-16 12:22 ` Sebastien Dugue
2008-09-16 12:22 ` Sebastien Dugue
2008-09-18 7:53 ` Christoph Raisch
2008-09-18 7:53 ` Christoph Raisch
2008-09-18 9:27 ` Sebastien Dugue
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 10:42 ` Christoph Raisch
2008-09-18 12:31 ` Sebastien Dugue
2008-09-18 12:31 ` Sebastien Dugue
2008-09-23 15:43 ` Jan-Bernd Themann
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 9:58 ` Milton Miller
2008-09-24 10:17 ` Benjamin Herrenschmidt
2008-09-24 10:17 ` Benjamin Herrenschmidt
2008-09-24 11:02 ` Milton Miller
2008-09-24 11:02 ` Milton Miller
2008-09-24 21:14 ` Benjamin Herrenschmidt
2008-09-24 21:14 ` Benjamin Herrenschmidt
2008-09-25 7:31 ` Sebastien Dugue
2008-09-25 7:31 ` Sebastien Dugue
2008-09-24 12:35 ` Sebastien Dugue
2008-09-24 12:35 ` Sebastien Dugue
2008-09-24 21:15 ` Benjamin Herrenschmidt [this message]
2008-09-24 21:15 ` Benjamin Herrenschmidt
2008-09-25 7:18 ` Sebastien Dugue
2008-09-25 7:18 ` Sebastien Dugue
2008-09-25 7:22 ` Benjamin Herrenschmidt
2008-09-25 7:22 ` Benjamin Herrenschmidt
2008-09-25 7:42 ` Sebastien Dugue
2008-09-25 7:42 ` Sebastien Dugue
2008-09-25 8:36 ` Benjamin Herrenschmidt
2008-09-25 8:36 ` Benjamin Herrenschmidt
2008-09-25 8:39 ` Sebastien Dugue
2008-09-25 8:39 ` Sebastien Dugue
2008-09-24 12:30 ` Sebastien Dugue
2008-09-24 12:30 ` Sebastien Dugue
2008-09-24 16:42 ` Milton Miller
2008-09-24 16:42 ` Milton Miller
2008-09-24 21:16 ` Benjamin Herrenschmidt
2008-09-24 21:16 ` Benjamin Herrenschmidt
2008-09-25 3:56 ` Milton Miller
2008-09-25 3:56 ` Milton Miller
2008-09-25 8:45 ` Sebastien Dugue
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-25 23:40 ` Milton Miller
2008-09-26 9:16 ` Sebastien Dugue
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=1222290917.8277.83.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=RAISCH@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.