public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: Zwane Mwaikambo <zwane@holomorphy.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Martin Bligh <mbligh@us.ibm.com>,
	John Stultz <johnstul@us.ibm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
Date: Thu, 12 Dec 2002 19:32:06 -0800	[thread overview]
Message-ID: <200212121932.06196.jamesclv@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.50.0212122221450.6931-100000@montezuma.mastecende.com>

On Thursday 12 December 2002 07:26 pm, Zwane Mwaikambo wrote:
> On Thu, 12 Dec 2002, Nakajima, Jun wrote:
> > BTW, we are working on a xAPIC patch that supports more than 8 CPUs in a
> > generic fashion (don't use hardcode OEM checking). We already tested it
> > on two OEM systems with 16 CPUs.
> > - It uses clustered mode. We don't want to use physical mode because it
> > does not support lowest priority delivery mode.
>
> Wouldn't that only be for all including self? Or is the documentation
> incorrect?
>
> Thanks,
> 	Zwane

I'm not sure I understand your question.  Lowest Priority delivery mode only 
works with logical interrupts.  (I've tried it with physical intrs.  It fails 
miserably.)  The "all including self" and "all excluding self" destination 
shorthands don't do lowest priority arbitration.  They always deliver the 
interrupt to the CPUs mentioned in the shortand.

Lowest priority delivery mode isn't _too_ useful in Linux yet.  It would be 
nice to preferentially target idle CPUs with interrupts in real time.  That 
means changing each CPU's Task Priority Register (TPR) to represent how busy 
it is.  I've got some patches to do that, but haven't posted them as anything 
more than a RFC.

-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com


  reply	other threads:[~2002-12-13  3:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-13  3:05 [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit Nakajima, Jun
2002-12-13  3:21 ` James Cleverdon
2002-12-13  3:26 ` Zwane Mwaikambo
2002-12-13  3:32   ` James Cleverdon [this message]
2002-12-13  5:53     ` Steffen Persvold
2002-12-13 19:32       ` James Cleverdon
  -- strict thread matches above, loose matches on Subject: below --
2002-12-17  2:30 Nakajima, Jun
2002-12-13 20:41 Nakajima, Jun
2002-12-13 15:43 Nakajima, Jun
2002-12-13 19:40 ` James Cleverdon
2002-12-13  3:20 Nakajima, Jun
2002-12-13  1:44 Zwane Mwaikambo
2002-12-13  2:09 ` James Cleverdon
2002-12-13  2:21   ` Zwane Mwaikambo
2002-12-13  2:41     ` James Cleverdon
2002-12-13  3:11       ` Zwane Mwaikambo

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=200212121932.06196.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@us.ibm.com \
    --cc=zwane@holomorphy.com \
    /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