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
next prev parent 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