linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: <linux-mm@kvack.org>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <x86@kernel.org>,
	Keith Busch <keith.busch@intel.com>, <jglisse@redhat.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>, <linuxarm@huawei.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH V5 3/4] x86: Support Generic Initiator only proximity domains
Date: Tue, 8 Oct 2019 12:17:29 +0100	[thread overview]
Message-ID: <20191008121729.00005ee9@huawei.com> (raw)
In-Reply-To: <20191007145505.GB88143@gmail.com>

On Mon, 7 Oct 2019 16:55:05 +0200
Ingo Molnar <mingo@kernel.org> wrote:

> * Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> 
> > Done in a somewhat different fashion to arm64.
> > Here the infrastructure for memoryless domains was already
> > in place.  That infrastruture applies just as well to
> > domains that also don't have a CPU, hence it works for
> > Generic Initiator Domains.
> > 
> > In common with memoryless domains we only register GI domains
> > if the proximity node is not online. If a domain is already
> > a memory containing domain, or a memoryless domain there is
> > nothing to do just because it also contains a Generic Initiator.
> > 
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > ---
> >  arch/x86/include/asm/numa.h |  2 ++
> >  arch/x86/kernel/setup.c     |  1 +
> >  arch/x86/mm/numa.c          | 14 ++++++++++++++
> >  3 files changed, 17 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> > index bbfde3d2662f..f631467272a3 100644
> > --- a/arch/x86/include/asm/numa.h
> > +++ b/arch/x86/include/asm/numa.h
> > @@ -62,12 +62,14 @@ extern void numa_clear_node(int cpu);
> >  extern void __init init_cpu_to_node(void);
> >  extern void numa_add_cpu(int cpu);
> >  extern void numa_remove_cpu(int cpu);
> > +extern void init_gi_nodes(void);
> >  #else	/* CONFIG_NUMA */
> >  static inline void numa_set_node(int cpu, int node)	{ }
> >  static inline void numa_clear_node(int cpu)		{ }
> >  static inline void init_cpu_to_node(void)		{ }
> >  static inline void numa_add_cpu(int cpu)		{ }
> >  static inline void numa_remove_cpu(int cpu)		{ }
> > +static inline void init_gi_nodes(void)			{ }
> >  #endif	/* CONFIG_NUMA */
> >  
> >  #ifdef CONFIG_DEBUG_PER_CPU_MAPS
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index cfb533d42371..b6c977907ea5 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1264,6 +1264,7 @@ void __init setup_arch(char **cmdline_p)
> >  	prefill_possible_map();
> >  
> >  	init_cpu_to_node();
> > +	init_gi_nodes();
> >  
> >  	io_apic_init_mappings();
> >  
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 4123100e0eaf..50bf724a425e 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -733,6 +733,20 @@ static void __init init_memory_less_node(int nid)
> >  	 */
> >  }
> >  
> > +/*
> > + * Generic Initiator Nodes may have neither CPU nor Memory.
> > + * At this stage if either of the others were present we would
> > + * already be online.
> > + */
> > +void __init init_gi_nodes(void)
> > +{
> > +	int nid;
> > +
> > +	for_each_node_state(nid, N_GENERIC_INITIATOR)
> > +		if (!node_online(nid))
> > +			init_memory_less_node(nid);
> > +}  
> 
> Nit: missing curly braces.

Good point.

> 
> How do these work in practice, will a system that only had nodes 0-1 
> today grow a third node '2' that won't have any CPUs on memory on them?

Yes. Exactly that.  The result is that fallback lists etc work when
_PXM is used to assign a device into that new node.  The interesting
bit comes when a driver does something more interesting and queries
the numa distances from SLIT.  At that point the driver can elect to
do load balancing across multiple nodes at similar distances.

In theory you can also specify a device you wish to put into the node
via the SRAT entry (IIRC using segment + BDF for PCI devices), but
for now I haven't implemented that method.

> 
> Thanks,
> 
> 	Ingo

Thanks,

Jonathan



  reply	other threads:[~2019-10-08 11:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 11:43 [PATCH V5 0/4] ACPI: Support Generic Initiator proximity domains Jonathan Cameron
2019-10-04 11:43 ` [PATCH V5 1/4] ACPI: Support Generic Initiator only domains Jonathan Cameron
2019-10-18 10:18   ` Rafael J. Wysocki
2019-10-18 12:46     ` Jonathan Cameron
2019-11-07 14:54       ` Rafael J. Wysocki
2019-11-12 17:07         ` Jonathan Cameron
2019-11-12 17:55   ` Dan Williams
2019-11-13  9:47     ` Jonathan Cameron
2019-11-13 13:57       ` Tao Xu
2019-11-13 16:52         ` Dan Williams
2019-11-13 17:56           ` Jonathan Cameron
2019-11-13 17:48         ` Jonathan Cameron
2019-11-13 23:20           ` Dan Williams
2019-11-14 11:26             ` Jonathan Cameron
2019-11-16 20:45               ` Dan Williams
2019-11-18 17:18                 ` Brice Goglin
2019-10-04 11:43 ` [PATCH V5 2/4] arm64: " Jonathan Cameron
2019-10-04 11:43 ` [PATCH V5 3/4] x86: Support Generic Initiator only proximity domains Jonathan Cameron
2019-10-07 14:55   ` Ingo Molnar
2019-10-08 11:17     ` Jonathan Cameron [this message]
2019-10-04 11:43 ` [PATCH V5 4/4] ACPI: Let ACPI know we support Generic Initiator Affinity Structures Jonathan Cameron

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=20191008121729.00005ee9@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=jglisse@redhat.com \
    --cc=keith.busch@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --cc=mingo@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=x86@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 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).