All of lore.kernel.org
 help / color / mirror / Atom feed
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Date: Fri, 14 Oct 2016 17:58:35 +0100	[thread overview]
Message-ID: <20161014165835.GA24546@red-moon> (raw)
In-Reply-To: <c8b9f6fc-3a4b-f74a-c930-f500bcc00a1d@redhat.com>

On Fri, Oct 14, 2016 at 06:22:55PM +0200, Laszlo Ersek wrote:
> On 10/14/16 17:42, Lorenzo Pieralisi wrote:
> > On Fri, Oct 14, 2016 at 05:27:58PM +0200, Laszlo Ersek wrote:
> >> On 10/14/16 17:01, Laszlo Ersek wrote:
> >>
> >>> Maybe the code I
> >>> tried to analyze in this email was never *meant* to associate CPU#0 with
> >>> any NUMA node at all (not even node 0); instead, other code -- for
> >>> example code removed by 7ba5f605f3a0 -- was meant to perform that
> >>> association.
> >>
> >> Staring a bit more at the code, this looks very likely; in acpi_map_gic_cpu_interface() we have
> >>
> >>> 	/* Check if GICC structure of boot CPU is available in the MADT */
> >>> 	if (cpu_logical_map(0) == hwid) {
> >>> 		if (bootcpu_valid) {
> >>> 			pr_err("duplicate boot CPU MPIDR: 0x%llx in MADT\n",
> >>> 			       hwid);
> >>> 			return;
> >>> 		}
> >>> 		bootcpu_valid = true;
> >>> 		return;
> >>> 	}
> >>
> >> which means that this callback function (for parsing the GICC
> >> structures in the MADT) expects to find the boot processor as well.
> >>
> >> Upon finding the boot processor, we set bootcpu_valid to true, and
> >> that's it -- no association with any NUMA node, and no incrementing of
> >> "cpu_count".
> > 
> > Yes, because that's to check the MADT contains the boot cpu hwid.
> > 
> > Does this help (compile tested only) ?
> > 
> > -- >8 -- 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index d3f151c..8507703 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -544,6 +544,7 @@ static int __init smp_cpu_setup(int cpu)
> >  			return;
> >  		}
> >  		bootcpu_valid = true;
> > +		early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> >  		return;
> >  	}
> >  
> > 
> 
> Your patch applies to the tree at v4.8-14604-g29fbff8698fc, but the function the hunk modifies is not smp_cpu_setup(), it is acpi_map_gic_cpu_interface():
> 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index d3f151cfd4a1..8507703dabe4 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> >  			return;
> >  		}
> >  		bootcpu_valid = true;
> > +		early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> >  		return;
> >  	}
> > 
> 
> Anyway, your patch works with both the two-node NUMA configuration
> Drew suggested for testing, and with the single-node config that I
> originally used for the bisection. Therefore:
> 
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> 
> Thank you very much for the quick bugfix! And, I think your patch
> (when you send it for real) should carry
> 
> Fixes: 7ba5f605f3a0d9495aad539eeb8346d726dfc183
> 
> too, because it supplies the cpu#0<->node#xxx association that
> 7ba5f605f3a0 removed not just for DT, but also for ACPI.

Sure, will do, I will send it out on Monday.

Cheers,
Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Will Deacon <will.deacon@arm.com>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	main kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Shannon Zhao <shannon.zhao@linaro.org>,
	Wei Huang <wei@redhat.com>
Subject: Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Date: Fri, 14 Oct 2016 17:58:35 +0100	[thread overview]
Message-ID: <20161014165835.GA24546@red-moon> (raw)
In-Reply-To: <c8b9f6fc-3a4b-f74a-c930-f500bcc00a1d@redhat.com>

On Fri, Oct 14, 2016 at 06:22:55PM +0200, Laszlo Ersek wrote:
> On 10/14/16 17:42, Lorenzo Pieralisi wrote:
> > On Fri, Oct 14, 2016 at 05:27:58PM +0200, Laszlo Ersek wrote:
> >> On 10/14/16 17:01, Laszlo Ersek wrote:
> >>
> >>> Maybe the code I
> >>> tried to analyze in this email was never *meant* to associate CPU#0 with
> >>> any NUMA node at all (not even node 0); instead, other code -- for
> >>> example code removed by 7ba5f605f3a0 -- was meant to perform that
> >>> association.
> >>
> >> Staring a bit more at the code, this looks very likely; in acpi_map_gic_cpu_interface() we have
> >>
> >>> 	/* Check if GICC structure of boot CPU is available in the MADT */
> >>> 	if (cpu_logical_map(0) == hwid) {
> >>> 		if (bootcpu_valid) {
> >>> 			pr_err("duplicate boot CPU MPIDR: 0x%llx in MADT\n",
> >>> 			       hwid);
> >>> 			return;
> >>> 		}
> >>> 		bootcpu_valid = true;
> >>> 		return;
> >>> 	}
> >>
> >> which means that this callback function (for parsing the GICC
> >> structures in the MADT) expects to find the boot processor as well.
> >>
> >> Upon finding the boot processor, we set bootcpu_valid to true, and
> >> that's it -- no association with any NUMA node, and no incrementing of
> >> "cpu_count".
> > 
> > Yes, because that's to check the MADT contains the boot cpu hwid.
> > 
> > Does this help (compile tested only) ?
> > 
> > -- >8 -- 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index d3f151c..8507703 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -544,6 +544,7 @@ static int __init smp_cpu_setup(int cpu)
> >  			return;
> >  		}
> >  		bootcpu_valid = true;
> > +		early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> >  		return;
> >  	}
> >  
> > 
> 
> Your patch applies to the tree at v4.8-14604-g29fbff8698fc, but the function the hunk modifies is not smp_cpu_setup(), it is acpi_map_gic_cpu_interface():
> 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index d3f151cfd4a1..8507703dabe4 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> >  			return;
> >  		}
> >  		bootcpu_valid = true;
> > +		early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> >  		return;
> >  	}
> > 
> 
> Anyway, your patch works with both the two-node NUMA configuration
> Drew suggested for testing, and with the single-node config that I
> originally used for the bisection. Therefore:
> 
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> 
> Thank you very much for the quick bugfix! And, I think your patch
> (when you send it for real) should carry
> 
> Fixes: 7ba5f605f3a0d9495aad539eeb8346d726dfc183
> 
> too, because it supplies the cpu#0<->node#xxx association that
> 7ba5f605f3a0 removed not just for DT, but also for ACPI.

Sure, will do, I will send it out on Monday.

Cheers,
Lorenzo

  reply	other threads:[~2016-10-14 16:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 22:50 aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0") Laszlo Ersek
2016-10-13 22:50 ` Laszlo Ersek
2016-10-14  8:05 ` Andrew Jones
2016-10-14  8:05   ` Andrew Jones
2016-10-14 13:18   ` Laszlo Ersek
2016-10-14 13:18     ` Laszlo Ersek
2016-10-14 13:44     ` Andrew Jones
2016-10-14 13:44       ` Andrew Jones
2016-10-14 15:45       ` Laszlo Ersek
2016-10-14 15:45         ` Laszlo Ersek
2016-10-14 15:01     ` Laszlo Ersek
2016-10-14 15:01       ` Laszlo Ersek
2016-10-14 15:27       ` Laszlo Ersek
2016-10-14 15:27         ` Laszlo Ersek
2016-10-14 15:42         ` Lorenzo Pieralisi
2016-10-14 15:42           ` Lorenzo Pieralisi
2016-10-14 16:22           ` Laszlo Ersek
2016-10-14 16:22             ` Laszlo Ersek
2016-10-14 16:58             ` Lorenzo Pieralisi [this message]
2016-10-14 16:58               ` Lorenzo Pieralisi
2016-10-17  8:04             ` Leizhen (ThunderTown)
2016-10-17  8:04               ` Leizhen (ThunderTown)

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=20161014165835.GA24546@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.