public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Cc: "Martin Bligh" <mbligh@us.ibm.com>,
	"John Stultz" <johnstul@us.ibm.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"Mallick, Asit K" <asit.k.mallick@intel.com>,
	"Saxena, Sunil" <sunil.saxena@intel.com>
Subject: Re: [PATCH][2.4]  generic cluster APIC support for systems with more than 8 CPUs
Date: Thu, 19 Dec 2002 18:04:55 -0800	[thread overview]
Message-ID: <200212191804.55194.jamesclv@us.ibm.com> (raw)
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E18E@fmsmsx405.fm.intel.com>

On Wednesday 18 December 2002 02:36 pm, Pallipadi, Venkatesh wrote:
> 2.4.21-pre1 (i386) based patch to fix the issues with systems having more
> than 8 CPUs, in a generic way.
>
>
> Motivation:
> The current APIC destination mode ("Flat Logical") used in linux kernel has
> an upper limit of 8 CPUs. For more than 8 CPUs, either "Clustered Logical"
> or "Physical" mode has to be used.
> There is already some code in current kernel (2.4.21-pre1), to support such
> conditions. Specifically, IBM Summit, uses Physical mode, and IBM NUMAQ
> uses clustered mode. But, there are some issues too:
> - it is not generic enough to support any other more than 8 CPU system
>   out of the box. Supporting different systems may need more hacks in the
> code. - clustered mode setup is tightly coupled with NUMA system. Whereas,
> in reality, we can as well have logical clusters in a non-NUMA system as
> well. - physical mode setup is somewhat tightly coupled with xAPIC. But,
> xAPIC doesn't necessarily imply physical mode. You can as well have
> clustered mode with xAPIC - APIC destination mode is selected based on
> particular OEM string.
>
> These reasons together led to panics on other OEM systems with > 8 CPUS.
> The patch tries to fix this issue in a generic way (in place of having
> multiple hacks for different OEMs). Note, the patch only intends to change
> the initialization of systems with more than 8 CPUs and it will not affect
> other systems (apart from possible bugs in my code itself).

Your goals are laudable and, in many ways, I share them.  However, this is 
2.4.  Our goals for 2.4 have always been minimal changes and as little impact 
as possible to the UP and flat SMP cases.

> Description:
> The basic idea is to use the number of processors detected on the system,
> to decide on which APIC destination mode is to be used. Once all the CPU
> info, is collected either from ACPI or MP table, we can check the total
> number of processors in the system.
> If the number of processors in less than equal to 8,
>    then no change is required, and we can use the default, "Flat Logical"
> set up. If the number of processors is more than 8
>    we can switch to clustered logical setup.
>    The logical clusters set up as follows.
>    Cluster 0 (CPU 0-3), Cluster 1 (CPU 4-7), Cluster 2 (CPU 8-11) and so
> on..
>
> The other things that are done in the patch include:
> - Separate out the NUMA specific stuff from APIC setup in cluster mode.
> Also, NUMA has its own way of setting up the clusters, and doesn't follow
> the logical cluster mapping defined above.
> - Separate out xAPIC stuff from APIC destination setup. And the
> availability of xAPIC support can actually  be determined from the LAPIC
> version. - physical mode support _removed_, as we can use clustered logical
> setup to support can support upto a max of 60 CPUs. This is mainly because
> of the advantage of being able to setup IOAPICs in LowestPrio, when using
> clustered mode.

See my 2.5 patches for an example of using solely logical mode interrupts.  
The patches submitted to 2.4 are those that have been in Alan's tree since 
August and running in SuSE 8.0+ since 8.0's release.

> The whole stuff is protected by 'Clustered APIC (> 8 CPUs) support
> (CONFIG_X86_APIC_CLUSTER)' config option under Processor Type and Features.
> But going forward, we can actually make this as default, as this doesn't
> affect the systems with less than equal to 8 CPUs (Apart from minor
> increase in code size and couple of additional checks during boot up), but
> gives the default support to more than 8 CPU systems.

An x440 needs to use clustered APIC mode whenever more than two physical CPUs 
are present.  Consider scanning the list of physical APIC IDs to determine 
whether clustered mode is necessary.  (I had such code in my 2.5 patch, but 
ripped it out when it falsely triggered on a couple oddball systems.  You may 
be able to write a more comprehensive analyzer.)

> Please let me know your comments/criticisms about this.
> I was able to test this successfully on an 8-way with HT(16 logical)
> CPU systems that I have access to. But, I haven't tested it on x440, or
> NUMAQ systems. Would love to hear about the effect of this patch on these
> systems.
>
> Thanks,
> -Venkatesh

A generic patch should also support Unisys' new box, the ES7000 or some such.

> > -----Original Message-----
> > From: Nakajima, Jun
> > Sent: Thursday, December 12, 2002 7:06 PM
> > To: jamesclv@us.ibm.com; Zwane Mwaikambo
> > Cc: Martin Bligh; John Stultz; Linux Kernel
> > Subject: RE: [PATCH][2.5][RFC] Using xAPIC apic address space
> > on !Summit
> >
> >
> > 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.
> > - We also check the version of the local APIC if it's xAPIC
> > or not. It's
> > possible that some other x86 architecture (other than P4P) uses xAPIC.
> >
> > Stay tuned.
> >
> > Jun

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


  parent reply	other threads:[~2002-12-20  1:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-18 22:36 [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs Pallipadi, Venkatesh
2002-12-18 23:26 ` Christoph Hellwig
2002-12-18 23:41   ` William Lee Irwin III
2002-12-18 23:59   ` Martin J. Bligh
2002-12-19  0:24 ` Martin J. Bligh
2002-12-20  2:04 ` James Cleverdon [this message]
2002-12-20  8:00   ` Christoph Hellwig
2002-12-20 11:24     ` William Lee Irwin III
2002-12-20 11:29       ` William Lee Irwin III
  -- strict thread matches above, loose matches on Subject: below --
2002-12-19  1:05 Pallipadi, Venkatesh
2002-12-19  1:32 ` James Cleverdon
2002-12-19  2:35 Pallipadi, Venkatesh
2002-12-19  3:10 ` Martin J. Bligh
2002-12-19  2:45 Pallipadi, Venkatesh
2002-12-19  4:14 ` James Cleverdon
2002-12-21  3:27 Nakajima, Jun
2002-12-21  4:43 ` Martin J. Bligh
2003-01-07 22:42 Andrew Theurer
2003-01-11  4:28 ` James Cleverdon
2003-01-08  3:19 Kamble, Nitin A

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=200212191804.55194.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=asit.k.mallick@intel.com \
    --cc=johnstul@us.ibm.com \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@us.ibm.com \
    --cc=sunil.saxena@intel.com \
    --cc=venkatesh.pallipadi@intel.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