All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dave Hansen <dave@sr71.net>
Cc: mingo@kernel.org, hpa@linux.intel.com, brice.goglin@gmail.com,
	bp@alien8.de, linux-kernel@vger.kernel.org,
	dave.hansen@linux.intel.com
Subject: Re: [RFC][PATCH 2/6] x86: introduce cpumask specifically for the package
Date: Thu, 18 Sep 2014 16:57:57 +0200	[thread overview]
Message-ID: <20140918145757.GR2840@worktop.localdomain> (raw)
In-Reply-To: <20140917223314.CEE1F258@viggo.jf.intel.com>

On Wed, Sep 17, 2014 at 03:33:14PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> As noted by multiple reports:
> 
> 	https://lkml.org/lkml/2014/9/15/1240
> 	https://lkml.org/lkml/2014/7/28/442
> 
> the sched domains code has some assumptions that break on newer
> AMD and Intel CPUs.  Namely, the code assumes that NUMA node
> boundaries always lie outside of a CPU package.  That assumption
> is no longer true with Intel's Cluster-on-Die found in Haswell
> CPUs (with a special BIOS config knob) and AMD's DCM feature.
> 
> Essentially, the 'cpu_core_map' is no longer suitable for
> enumerating all the CPUs in a physical package.
> 
> This patch introduces a new map which is specifically built by
> consulting the the physical package ids instead of inferring the
> information from NUMA nodes.
> 
> This still leaves us with a broken 'core_siblings_list' in sysfs,
> but a later patch will fix that up too.

If we do dynamic topology layout we don't need a second mask I think.
The machines that have multiple packages per node will simply present a
different sched_domain_topology than the machines that have multiple
nodes per package.

Specifically, in the former we include the package_mask as DIE level, in
the other case we leave it out entirely and rely on the SLIT table to
build the right domain topology.

  reply	other threads:[~2014-09-18 14:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17 22:33 [RFC][PATCH 0/6] fix topology for multi-NUMA-node CPUs Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 1/6] topology: rename topology_core_cpumask() to topology_package_cpumask() Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 2/6] x86: introduce cpumask specifically for the package Dave Hansen
2014-09-18 14:57   ` Peter Zijlstra [this message]
2014-09-17 22:33 ` [RFC][PATCH 3/6] x86: use package_map instead of core_map for sysfs Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 4/6] sched: eliminate "DIE" domain level when NUMA present Dave Hansen
2014-09-18 17:28   ` Peter Zijlstra
2014-09-17 22:33 ` [RFC][PATCH 5/6] sched: keep MC domain from crossing nodes OR packages Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 6/6] sched: consolidate config options Dave Hansen
2014-09-18 17:29   ` Peter Zijlstra
2014-09-19 19:15     ` Dave Hansen
2014-09-19 23:03       ` Peter Zijlstra
2014-09-18  7:45 ` [RFC][PATCH 0/6] fix topology for multi-NUMA-node CPUs Borislav Petkov
     [not found] ` <CAOjmkp8EGO0jicmdO=p6ATHz-hUJmWb+xoBLjOdLBUwwGzyhhg@mail.gmail.com>
2014-09-22 15:54   ` Aravind Gopalakrishnan

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=20140918145757.GR2840@worktop.localdomain \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=brice.goglin@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.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 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.