linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sebastien Dugue <sebastien.dugue@bull.net>
To: benh@kernel.crashing.org
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 09:18:27 +0200	[thread overview]
Message-ID: <20080925091827.29b5087c@bull.net> (raw)
In-Reply-To: <1222290917.8277.83.camel@pasglop>

On Thu, 25 Sep 2008 07:15:17 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 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.

  Yep, except as it behaves in way that the current -rt fasteoi flow
cannot handle.

> 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...

  That's what I gathered from looking at the sources.

  Thanks,

  Sebastien.

  

  

   
  

  reply	other threads:[~2008-09-25  7:18 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
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 [this message]
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=20080925091827.29b5087c@bull.net \
    --to=sebastien.dugue@bull.net \
    --cc=RAISCH@de.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=ossthema@de.ibm.com \
    --cc=paulus@samba.org \
    /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).