* Re: [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: David Miller @ 2018-09-01 5:55 UTC (permalink / raw)
To: david.gounaris; +Cc: qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-4-david.gounaris@infinera.com>
From: David Gounaris <david.gounaris@infinera.com>
Date: Wed, 29 Aug 2018 15:13:25 +0200
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
Please don't add such an extraneous empty line.
Thanks.
^ permalink raw reply
* Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
From: Benjamin Herrenschmidt @ 2018-09-01 4:54 UTC (permalink / raw)
To: Finn Thain, Mac User
Cc: Rob Herring, Frank Rowand, Chintan Pandya, linuxppc-dev
In-Reply-To: <alpine.LNX.2.21.1809010929350.228@nippy.intranet>
On Sat, 2018-09-01 at 09:36 +1000, Finn Thain wrote:
> > The patched kernel (Finn's vmlinux-4.18.0-00001-gd44cf7e41c19) boots
> > normally on my Beige G3 Desktop using BootX.
> >
>
> Ben sent two patches, so I picked the most recent one and applied it by
> hand due to corrupted whitespace.
Yup, evolution seems to have broken copy/pasting of patches in a
preformatted email lately ... ugh.
> The patch you tested was the one below.
^ permalink raw reply
* Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
From: Benjamin Herrenschmidt @ 2018-09-01 4:53 UTC (permalink / raw)
To: Mac User; +Cc: Rob Herring, fthain, Frank Rowand, Chintan Pandya, linuxppc-dev
In-Reply-To: <d3f5a177-10ee-1696-1ddf-41b7db62de6c@yahoo.com>
On Fri, 2018-08-31 at 06:28 -0600, Mac User wrote:
> On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
> >
> > ...
> > Assuming you are using BootX (or miBoot), can you try this patch ?
>
> Yes, I'm using BootX.
>
> Thanks to Finn for applying the patch (I wouldn't have been sure
> which source tree to apply it to).
>
> Thepatched kernel (Finn's vmlinux-4.18.0-00001-gd44cf7e41c19)
> boots normally on my Beige G3 Desktop using BootX.
>
> Thanks for working on this!
Well it's still a sign of something wrong with the new code, my patch
just band-aids by creating fake phandles. I would be interesting to
figure out what causes the new code to barf.
Cheers,
Ben.
^ permalink raw reply
* Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
From: Finn Thain @ 2018-08-31 23:36 UTC (permalink / raw)
To: Mac User
Cc: Benjamin Herrenschmidt, Rob Herring, Frank Rowand, Chintan Pandya,
linuxppc-dev
In-Reply-To: <d3f5a177-10ee-1696-1ddf-41b7db62de6c@yahoo.com>
On Fri, 31 Aug 2018, Mac User wrote:
> On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
> >
> > ...
> > Assuming you are using BootX (or miBoot), can you try this patch ?
>
> Yes, I'm using BootX.
>
> Thanks to Finn for applying the patch (I wouldn't have been sure which
> source tree to apply it to).
>
> The patched kernel (Finn's vmlinux-4.18.0-00001-gd44cf7e41c19) boots
> normally on my Beige G3 Desktop using BootX.
>
Ben sent two patches, so I picked the most recent one and applied it by
hand due to corrupted whitespace.
The patch you tested was the one below.
> Thanks for working on this!
>
Thanks for testing!
> -Stan
>
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index 3b3b0b9b3577..7fb1c7bb5835 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -37,6 +37,7 @@ static unsigned long __initdata bootx_dt_strend;
static unsigned long __initdata bootx_node_chosen;
static boot_infos_t * __initdata bootx_info;
static char __initdata bootx_disp_path[256];
+static int __initdata bootx_phandle;
/* Is boot-info compatible ? */
#define BOOT_INFO_IS_COMPATIBLE(bi) \
@@ -258,6 +259,8 @@ static void __init bootx_scan_dt_build_strings(unsigned long base,
namep = pp->name ? (char *)(base + pp->name) : NULL;
if (namep == NULL || strcmp(namep, "name") == 0)
goto next;
+ if (!strcmp(namep, "phandle") || !strcmp(namep, "linux,phandle"))
+ bootx_phandle = -1;
/* get/create string entry */
soff = bootx_dt_find_string(namep);
if (soff == 0)
@@ -330,6 +333,12 @@ static void __init bootx_scan_dt_build_struct(unsigned long base,
ppp = &pp->next;
}
+ /* add a phandle */
+ if (bootx_phandle > 0) {
+ bootx_dt_add_prop("phandle", &bootx_phandle, 4, mem_end);
+ bootx_phandle++;
+ }
+
if (node == bootx_node_chosen) {
bootx_add_chosen_props(base, mem_end);
if (bootx_info->dispDeviceRegEntryOffset == 0)
@@ -385,6 +394,8 @@ static unsigned long __init bootx_flatten_dt(unsigned long start)
bootx_dt_add_string("linux,bootx-height", &mem_end);
bootx_dt_add_string("linux,bootx-linebytes", &mem_end);
bootx_dt_add_string("linux,bootx-addr", &mem_end);
+ if (bootx_phandle > 0)
+ bootx_dt_add_string("phandle", &mem_end);
/* Wrap up strings */
hdr->off_dt_strings = bootx_dt_strbase - mem_start;
hdr->dt_strings_size = bootx_dt_strend - bootx_dt_strbase;
@@ -482,6 +493,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
bootx_dt_strbase = bootx_dt_strend = 0;
bootx_node_chosen = 0;
bootx_disp_path[0] = 0;
+ bootx_phandle = 1;
if (!BOOT_INFO_IS_V2_COMPATIBLE(bi))
bi->logicalDisplayBase = bi->dispDeviceBase;
--
^ permalink raw reply related
* Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
From: Oscar Salvador @ 2018-08-31 20:54 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-mm, linux-kernel, linux-doc, linuxppc-dev, linux-acpi,
xen-devel, devel, Andrew Morton, Balbir Singh,
Benjamin Herrenschmidt, Boris Ostrovsky, Dan Williams,
Greg Kroah-Hartman, Haiyang Zhang, Heiko Carstens, John Allen,
Jonathan Corbet, Joonsoo Kim, Juergen Gross, Kate Stewart,
K. Y. Srinivasan, Len Brown, Martin Schwidefsky,
Mathieu Malaterre, Michael Ellerman, Michael Neuling,
Michal Hocko, Nathan Fontenot, Oscar Salvador, Paul Mackerras,
Pavel Tatashin, Philippe Ombredanne, Rafael J. Wysocki,
Rashmica Gupta, Stephen Hemminger, Thomas Gleixner,
Vlastimil Babka, YASUAKI ISHIMATSU
In-Reply-To: <20180821104418.12710-1-david@redhat.com>
On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
Hi David,
I would like to review this but I am on vacation, so I will not be able to get to it
soon.
I plan to do it once I am back.
Thanks
--
Oscar Salvador
SUSE L3
^ permalink raw reply
* Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2018-08-31 20:28 UTC (permalink / raw)
To: Andy Tang, Vabhav Sharma, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com
Cc: Yogesh Narayan Gaur, linux@armlinux.org.uk, Varun Sethi,
Udit Kumar
In-Reply-To: <DB5PR0401MB22130C025AA4CCAD0221781DF30F0@DB5PR0401MB2213.eurprd04.prod.outlook.com>
On Fri, 2018-08-31 at 06:12 +0000, Andy Tang wrote:
> Hi Scott,
>
> Please see my replay inline.
>
> > -----Original Message-----
> > From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org>
> > On Behalf Of Scott Wood
> > Sent: 2018年8月31日 1:43
> > To: Vabhav Sharma <vabhav.sharma@nxp.com>;
> > linux-kernel@vger.kernel.org; devicetree@vger.kernel.org;
> > robh+dt@kernel.org; mark.rutland@arm.com;
> > linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> > mturquette@baylibre.com; sboyd@kernel.org; rjw@rjwysocki.net;
> > viresh.kumar@linaro.org; linux-clk@vger.kernel.org;
> > linux-pm@vger.kernel.org; linux-kernel-owner@vger.kernel.org;
> > catalin.marinas@arm.com; will.deacon@arm.com;
> > gregkh@linuxfoundation.org; arnd@arndb.de;
> > kstewart@linuxfoundation.org; yamada.masahiro@socionext.com
> > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Andy Tang
> > <andy.tang@nxp.com>; linux@armlinux.org.uk; Varun Sethi
> > <V.Sethi@nxp.com>; Udit Kumar <udit.kumar@nxp.com>
> > Subject: Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for
> > lx2160a
> >
> > On Thu, 2018-08-30 at 12:39 -0500, Scott Wood wrote:
> > > On Thu, 2018-08-30 at 07:36 +0000, Vabhav Sharma wrote:
> > > > >
> > > > > Why are you increasing NUM_CMUX beyond 8 for a chip that only
> >
> > has
> > > > > 8 entries in cmux_to_group?
> > > >
> > > > Configuration is 16 cores,8 cluster with 2 cores in each cluster
> > >
> > > So? This is about cmuxes, not cores. You're increasing the array
> > > without ever using the new size.
> >
> > Oh, and you also broke p4080 which has 8 cmuxes but no -1 terminator,
> > because the array was of length 8. Probably the array should be changed
> > to NUM_CMUX+1 so every array can be -1 terminated.
> >
>
> [Andy] How about we add -1 terminator to p4080 and increase NUM_CMUX to 16?
Why 16? What does such a change have to do with this chip, which according to
the rest of the patch has 8 cmuxes?
> We don't want to increase NUM_CMUX each time new soc with more cmuxes added.
You don't want to have to make a trivial change each time you exceed a limit
that has yet to be exceeded once since NUM_CMUX was added? This isn't ABI or
in any other way hard to change. It's right in the same file as the chip
description you'd be adding.
And even if a chip did come along with 16 cmuxes, you'd then need to increase
the array to 17 to hold the -1 if you don't want to leave a situation like the
p4080 is in now, where a chip's cmux array could be broken by increasing
NUM_CMUX further.
-Scott
^ permalink raw reply
* Re: [PATCH] treewide: remove current_text_addr
From: Nick Desaulniers @ 2018-08-31 16:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, deller, Andrew Morton, Eric W . Biederman,
Thomas Gleixner, mingo, Simon Horman, Nathan Chancellor,
Philippe Ombredanne, Kate Stewart, Greg KH, rth, ink, Matt Turner,
vgupta, linux, Catalin Marinas, Will Deacon, msalter,
jacquiot.aurelien, Yoshinori Sato, rkuo, tony.luck, fenghua.yu,
Geert Uytterhoeven, Michal Simek, ralf, paul.burton, jhogan,
Green Hu, deanbo422, lftan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, jejb, benh, paulus, mpe, palmer, aou, schwidefsky,
heiko.carstens, dalias, David S. Miller, gxt, x86, jdike, richard,
Chris Zankel, Max Filippov, Tobias Klauser, noamc, mickael.guene,
Nicolas Pitre, Kees Cook, Dave Martin, Marc Zyngier,
Alex Bennée, Laura Abbott, Yury Norov, Mark Rutland, chenhc,
macro, Arnd Bergmann, dhowells, sukadev, Nicholas Piggin,
aneesh.kumar, felix, linuxram, christophe.leroy, cohuck, gor,
nick.alcock, shannon.nelson, Nagarathnam Muthusamy, luto, bp,
dave.hansen, vkuznets, jkosina, linux-alpha, LKML, linux-snps-arc,
Linux ARM, linux-c6x-dev, uclinux-h8-devel, linux-hexagon,
linux-ia64, linux-m68k, linux-mips, nios2-dev, openrisc,
linux-parisc, linuxppc-dev, linux-riscv, linux-s390, linux-sh,
sparclinux, linux-um, hpa
In-Reply-To: <4d1a8f35-e2fc-70d2-ca0e-44b8574c86f1@zytor.com>
On Mon, Aug 27, 2018 at 6:34 AM H. Peter Anvin <hpa@zytor.com> wrote:
>
> On 08/27/18 06:11, Peter Zijlstra wrote:
> > On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
> >
> >> _THIS_IP_, however, is completely ill-defined, other than being an
> >> address *somewhere* in the same global function (not even necessarily
> >> the same function if the function is static!) As my experiment show, in
> >> many (nearly) cases gcc will hoist the address all the way to the top of
> >> the function, at least for the current generic implementation.
> >
> > It seems to have mostly worked so far... did anything change?
> >
>
> Most likely because the major architectures contain a arch-specific
> assembly implementation. The generic implementation used in some places
> is completely broken, as my experiments show.
>
> >> For the case where _THIS_IP_ is passed to an out-of-line function in all
> >> cases, it is extra pointless because all it does is increase the
> >> footprint of every caller: _RET_IP_ is inherently passed to the function
> >> anyway, and with tailcall protection it will uniquely identify a callsite.
> >
> > So I think we can convert many of the lockdep _THIS_IP_ calls to
> > _RET_IP_ on the other side, with a wee bit of care.
> >
> > A little something like so perhaps...
>
> I don't have time to look at this right now (I'm on sabbatical, and I'm
> dealing with personal legal stuff right at the moment), but I think it
> is the right direction.
>
> -hpa
Linus,
Can this patch please be merged? Then we can polish off Peter's
change to lockdep to not even use _THIS_IP_.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
From: David Hildenbrand @ 2018-08-31 13:12 UTC (permalink / raw)
To: Pasha Tatashin, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
xen-devel@lists.xenproject.org, devel@linuxdriverproject.org,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Rafael J. Wysocki, Len Brown, Rashmica Gupta, Michael Neuling,
Balbir Singh, Nathan Fontenot, John Allen, Andrew Morton,
Michal Hocko, Dan Williams, Joonsoo Kim, Vlastimil Babka,
Greg Kroah-Hartman, Oscar Salvador, YASUAKI ISHIMATSU,
Mathieu Malaterre
In-Reply-To: <46a0119b-da16-0203-a8c2-d127738517f4@microsoft.com>
On 30.08.2018 21:35, Pasha Tatashin wrote:
>> +
>> +void __ref remove_memory(int nid, u64 start, u64 size)
>
> Remove __ref, otherwise looks good:
Indeed, will do.
Thanks for the review. Will resend in two weeks when I'm back from vacation.
Cheers!
>
> Reviewed-by: Pavel Tatashin <pavel.tatashin@microsoft.com>
>
>> +{
>> + lock_device_hotplug();
>> + __remove_memory(nid, start, size);
>> + unlock_device_hotplug();
>> +}
>> EXPORT_SYMBOL_GPL(remove_memory);
>> #endif /* CONFIG_MEMORY_HOTREMOVE */
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Srikar Dronamraju @ 2018-08-31 11:53 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180831112639.GA24142@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> [2018-08-31 13:26:39]:
> On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> > NAK, not until you've fixed every cpu_to_node() user in the kernel to
> > deal with that mask changing.
>
> Also, what happens if userspace reads that information; uses libnuma and
> then you go and shift the world underneath their feet?
>
> > This is absolutely insane.
>
The topology events are suppose to be very rare.
>From whatever small experiments I have done till now, unless tasks are
bound to both cpu and memory, they seem to be coping well with topology
updates. I know things weren't optimal after a topology change but they
worked. Now after 051f3ca02e46 "Introduce NUMA identity node sched
domain", systems stall. I am only exploring at ways to keep them working
as much as they were before that commit.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Peter Zijlstra @ 2018-08-31 12:08 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180831115350.GC8437@linux.vnet.ibm.com>
On Fri, Aug 31, 2018 at 04:53:50AM -0700, Srikar Dronamraju wrote:
> The topology events are suppose to be very rare.
> From whatever small experiments I have done till now, unless tasks are
> bound to both cpu and memory, they seem to be coping well with topology
> updates.
IOW, if you're not using NUMA, it works if you change the NUMA setup.
You don't see anything wrong with that?!
Those programs would work as well if you didn't expose the NUMA stuff,
because they're not using it anyway.
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Peter Zijlstra @ 2018-08-31 12:05 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180831115350.GC8437@linux.vnet.ibm.com>
On Fri, Aug 31, 2018 at 04:53:50AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@infradead.org> [2018-08-31 13:26:39]:
>
> > On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> > > NAK, not until you've fixed every cpu_to_node() user in the kernel to
> > > deal with that mask changing.
> >
> > Also, what happens if userspace reads that information; uses libnuma and
> > then you go and shift the world underneath their feet?
> >
> > > This is absolutely insane.
> >
>
> The topology events are suppose to be very rare.
> From whatever small experiments I have done till now, unless tasks are
> bound to both cpu and memory, they seem to be coping well with topology
> updates. I know things weren't optimal after a topology change but they
> worked. Now after 051f3ca02e46 "Introduce NUMA identity node sched
> domain", systems stall. I am only exploring at ways to keep them working
> as much as they were before that commit.
I'm saying things were fundamentally buggered and this just made it show.
If you cannot guarantee cpu:node relations, you do not have NUMA, end of
story.
^ permalink raw reply
* Re: [PATCH] sched/topology: Use Identity node only if required
From: Peter Zijlstra @ 2018-08-31 12:06 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Andre Wild, Benjamin Herrenschmidt
In-Reply-To: <20180831112618.GA10911@linux.vnet.ibm.com>
On Fri, Aug 31, 2018 at 04:56:18PM +0530, Srikar Dronamraju wrote:
> This was the same in my previous posting too. Before the topology update
> happened, all the cpus would be in SMT, DIE. The topology updates can be
> disabled using a kernel parameter topology_updates=off. Its documented under
> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html as
>
> topology_updates= [KNL, PPC, NUMA] Format: {off} Specify if the kernel
> should ignore (off) topology updates sent by the hypervisor to this
> LPAR.
>
> and is not something new in powerpc.
Doesn't mean it isn't utterly broken.
^ permalink raw reply
* Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
From: Mac User @ 2018-08-31 12:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rob Herring, fthain, Frank Rowand, Chintan Pandya, linuxppc-dev
In-Reply-To: <a825ebf4c01f862075006370f418e0b7ab4626ad.camel@kernel.crashing.org>
On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> ...
> Assuming you are using BootX (or miBoot), can you try this patch ?
Yes, I'm using BootX.
Thanks to Finn for applying the patch (I wouldn't have been sure
which source tree to apply it to).
Thepatched kernel (Finn's vmlinux-4.18.0-00001-gd44cf7e41c19)
boots normally on my Beige G3 Desktop using BootX.
Thanks for working on this!
-Stan
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Jiri Slaby @ 2018-08-31 12:28 UTC (permalink / raw)
To: Pasha Tatashin
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <5070bde7-d20e-a464-a566-e97a13264b94@microsoft.com>
On 08/31/2018, 02:10 PM, Pasha Tatashin wrote:
> Thanks Jiri, I am now able to reproduce it with your new config.
>
> I have tried yesterday to enable sparsemem and deferred_struct_init on
> x86_32, and that kernel booted fine, there must be something else in
> your config that helps to trigger this problem. I am studying it now.
>
> [ 0.051245] Initializing CPU#0
> [ 0.051682] Initializing HighMem for node 0 (000367fe:0007ffe0)
> [ 0.067499] BUG: unable to handle kernel NULL pointer dereference at
> 00000028
> [ 0.068452] *pdpt = 0000000000000000 *pde = f000ff53f000ff53
> [ 0.069105] Oops: 0000 [#1] PREEMPT SMP PTI
> [ 0.069595] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.19.0-rc1-pae_pt_jiri #1
> [ 0.070382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.11.0-20171110_100015-anatol 04/01/2014
> [ 0.071545] EIP: free_unref_page_prepare.part.70+0x2c/0x50
> [ 0.072178] Code: 19 e9 ff 89 d1 55 c1 ea 11 c1 e9 07 8b 14 d5 44 52
> fd d6 81 e1 fc 03 00 00 89 e5 56 53 89 cb be 1d 00 00 00 c1 eb 05 83 e1
> 1f <8b> 14 9a 29 ce 89 f1 d3 ea 83 e2 07 89 50 10 b8 01 00 00 00 5b 5e
> [ 0.074296] EAX: f4cfa000 EBX: 0000000a ECX: 00000010 EDX: 00000000
> [ 0.075005] ESI: 0000001d EDI: 0007ffe0 EBP: d6d41ed0 ESP: d6d41ec8
> [ 0.075714] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210002
> [ 0.076508] CR0: 80050033 CR2: 00000028 CR3: 16f20000 CR4: 000406b0
> [ 0.077242] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 0.077934] DR6: fffe0ff0 DR7: 00000400
> [ 0.078380] Call Trace:
> [ 0.078670] free_unref_page+0x3a/0x90
> [ 0.079136] __free_pages+0x25/0x30
> [ 0.079533] free_highmem_page+0x1e/0x50
> [ 0.079978] add_highpages_with_active_regions+0xd1/0x11f
> [ 0.080592] set_highmem_pages_init+0x67/0x7d
> [ 0.081076] mem_init+0x30/0x1fc
page_to_pfn(pfn_to_page(pfn)) != pfn with my .config on pfns >= 0x60000:
[ 0.157667] add_highpages_with_active_regions: pfn=5fffb pg=f55f9f4c
pfn(pg(pfn)=5fffb sec=2
[ 0.159231] add_highpages_with_active_regions: pfn=5fffc pg=f55f9f70
pfn(pg(pfn)=5fffc sec=2
[ 0.161020] add_highpages_with_active_regions: pfn=5fffd pg=f55f9f94
pfn(pg(pfn)=5fffd sec=2
[ 0.163149] add_highpages_with_active_regions: pfn=5fffe pg=f55f9fb8
pfn(pg(pfn)=5fffe sec=2
[ 0.165204] add_highpages_with_active_regions: pfn=5ffff pg=f55f9fdc
pfn(pg(pfn)=5ffff sec=2
[ 0.167216] add_highpages_with_active_regions: pfn=60000 pg=f4cfa000
pfn(pg(pfn)=c716a800 sec=3
So add_highpages_with_active_regions passes down page to
free_highmem_page and later, free_unref_page does page_to_pfn(page) and
__get_pfnblock_flags_mask operates on this modified pfn leading to crash
– __pfn_to_section(pfn)->pageblock_flags is NULL!
Note that __pfn_to_section(pfn)->pageblock_flags on the original pfn
returns a valid bitmap.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Pasha Tatashin @ 2018-08-31 12:10 UTC (permalink / raw)
To: Jiri Slaby
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <0acf1c74-1bd3-e425-f92b-5d084ff954a4@suse.cz>
VGhhbmtzIEppcmksIEkgYW0gbm93IGFibGUgdG8gcmVwcm9kdWNlIGl0IHdpdGggeW91ciBuZXcg
Y29uZmlnLg0KDQpJIGhhdmUgdHJpZWQgeWVzdGVyZGF5IHRvIGVuYWJsZSBzcGFyc2VtZW0gYW5k
IGRlZmVycmVkX3N0cnVjdF9pbml0IG9uDQp4ODZfMzIsIGFuZCB0aGF0IGtlcm5lbCBib290ZWQg
ZmluZSwgdGhlcmUgbXVzdCBiZSBzb21ldGhpbmcgZWxzZSBpbg0KeW91ciBjb25maWcgdGhhdCBo
ZWxwcyB0byB0cmlnZ2VyIHRoaXMgcHJvYmxlbS4gSSBhbSBzdHVkeWluZyBpdCBub3cuDQoNClsg
ICAgMC4wNTEyNDVdIEluaXRpYWxpemluZyBDUFUjMA0KWyAgICAwLjA1MTY4Ml0gSW5pdGlhbGl6
aW5nIEhpZ2hNZW0gZm9yIG5vZGUgMCAoMDAwMzY3ZmU6MDAwN2ZmZTApDQpbICAgIDAuMDY3NDk5
XSBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBh
dA0KMDAwMDAwMjgNClsgICAgMC4wNjg0NTJdICpwZHB0ID0gMDAwMDAwMDAwMDAwMDAwMCAqcGRl
ID0gZjAwMGZmNTNmMDAwZmY1Mw0KWyAgICAwLjA2OTEwNV0gT29wczogMDAwMCBbIzFdIFBSRUVN
UFQgU01QIFBUSQ0KWyAgICAwLjA2OTU5NV0gQ1BVOiAwIFBJRDogMCBDb21tOiBzd2FwcGVyIE5v
dCB0YWludGVkDQo0LjE5LjAtcmMxLXBhZV9wdF9qaXJpICMxDQpbICAgIDAuMDcwMzgyXSBIYXJk
d2FyZSBuYW1lOiBRRU1VIFN0YW5kYXJkIFBDIChpNDQwRlggKyBQSUlYLCAxOTk2KSwNCkJJT1Mg
MS4xMS4wLTIwMTcxMTEwXzEwMDAxNS1hbmF0b2wgMDQvMDEvMjAxNA0KWyAgICAwLjA3MTU0NV0g
RUlQOiBmcmVlX3VucmVmX3BhZ2VfcHJlcGFyZS5wYXJ0LjcwKzB4MmMvMHg1MA0KWyAgICAwLjA3
MjE3OF0gQ29kZTogMTkgZTkgZmYgODkgZDEgNTUgYzEgZWEgMTEgYzEgZTkgMDcgOGIgMTQgZDUg
NDQgNTINCmZkIGQ2IDgxIGUxIGZjIDAzIDAwIDAwIDg5IGU1IDU2IDUzIDg5IGNiIGJlIDFkIDAw
IDAwIDAwIGMxIGViIDA1IDgzIGUxDQoxZiA8OGI+IDE0IDlhIDI5IGNlIDg5IGYxIGQzIGVhIDgz
IGUyIDA3IDg5IDUwIDEwIGI4IDAxIDAwIDAwIDAwIDViIDVlDQpbICAgIDAuMDc0Mjk2XSBFQVg6
IGY0Y2ZhMDAwIEVCWDogMDAwMDAwMGEgRUNYOiAwMDAwMDAxMCBFRFg6IDAwMDAwMDAwDQpbICAg
IDAuMDc1MDA1XSBFU0k6IDAwMDAwMDFkIEVESTogMDAwN2ZmZTAgRUJQOiBkNmQ0MWVkMCBFU1A6
IGQ2ZDQxZWM4DQpbICAgIDAuMDc1NzE0XSBEUzogMDA3YiBFUzogMDA3YiBGUzogMDBkOCBHUzog
MDBlMCBTUzogMDA2OCBFRkxBR1M6IDAwMjEwMDAyDQpbICAgIDAuMDc2NTA4XSBDUjA6IDgwMDUw
MDMzIENSMjogMDAwMDAwMjggQ1IzOiAxNmYyMDAwMCBDUjQ6IDAwMDQwNmIwDQpbICAgIDAuMDc3
MjQyXSBEUjA6IDAwMDAwMDAwIERSMTogMDAwMDAwMDAgRFIyOiAwMDAwMDAwMCBEUjM6IDAwMDAw
MDAwDQpbICAgIDAuMDc3OTM0XSBEUjY6IGZmZmUwZmYwIERSNzogMDAwMDA0MDANClsgICAgMC4w
NzgzODBdIENhbGwgVHJhY2U6DQpbICAgIDAuMDc4NjcwXSAgZnJlZV91bnJlZl9wYWdlKzB4M2Ev
MHg5MA0KWyAgICAwLjA3OTEzNl0gIF9fZnJlZV9wYWdlcysweDI1LzB4MzANClsgICAgMC4wNzk1
MzNdICBmcmVlX2hpZ2htZW1fcGFnZSsweDFlLzB4NTANClsgICAgMC4wNzk5NzhdICBhZGRfaGln
aHBhZ2VzX3dpdGhfYWN0aXZlX3JlZ2lvbnMrMHhkMS8weDExZg0KWyAgICAwLjA4MDU5Ml0gIHNl
dF9oaWdobWVtX3BhZ2VzX2luaXQrMHg2Ny8weDdkDQpbICAgIDAuMDgxMDc2XSAgbWVtX2luaXQr
MHgzMC8weDFmYw0KWyAgICAwLjA4MTQzNF0gIHN0YXJ0X2tlcm5lbCsweDFjYy8weDQ0Yw0KWyAg
ICAwLjA4MTg3NF0gIGkzODZfc3RhcnRfa2VybmVsKzB4OTgvMHg5Yw0KWyAgICAwLjA4MjQwMV0g
IHN0YXJ0dXBfMzJfc21wKzB4MTY0LzB4MTY4DQpbICAgIDAuMDgyODczXSBNb2R1bGVzIGxpbmtl
ZCBpbjoNClsgICAgMC4wODMyMjhdIENSMjogMDAwMDAwMDAwMDAwMDAyOA0KWyAgICAwLjA4MzYw
Nl0gLS0tWyBlbmQgdHJhY2UgYTU5OTBkOWFjZTJlYzk5MCBdLS0tDQpbICAgIDAuMDg0MTI4XSBF
SVA6IGZyZWVfdW5yZWZfcGFnZV9wcmVwYXJlLnBhcnQuNzArMHgyYy8weDUwDQpbICAgIDAuMDg0
NzQ3XSBDb2RlOiAxOSBlOSBmZiA4OSBkMSA1NSBjMSBlYSAxMSBjMSBlOSAwNyA4YiAxNCBkNSA0
NCA1Mg0KZmQgZDYgODEgZTEgZmMgMDMgMDAgMDAgODkgZTUgNTYgNTMgODkgY2IgYmUgMWQgMDAg
MDAgMDAgYzEgZWIgMDUgODMgZTENCjFmIDw4Yj4gMTQgOWEgMjkgY2UgODkgZjEgZDMgZWEgODMg
ZTIgMDcgODkgNTAgMTAgYjggMDEgMDAgMDAgMDAgNWIgNWUNClsgICAgMC4wODY4NzRdIEVBWDog
ZjRjZmEwMDAgRUJYOiAwMDAwMDAwYSBFQ1g6IDAwMDAwMDEwIEVEWDogMDAwMDAwMDANClsgICAg
MC4wODc1ODFdIEVTSTogMDAwMDAwMWQgRURJOiAwMDA3ZmZlMCBFQlA6IGQ2ZDQxZWQwIEVTUDog
ZDZmMjdlZmMNClsgICAgMC4wODgyODddIERTOiAwMDdiIEVTOiAwMDdiIEZTOiAwMGQ4IEdTOiAw
MGUwIFNTOiAwMDY4IEVGTEFHUzogMDAyMTAwMDINClsgICAgMC4wODkxMzldIENSMDogODAwNTAw
MzMgQ1IyOiAwMDAwMDAyOCBDUjM6IDE2ZjIwMDAwIENSNDogMDAwNDA2YjANClsgICAgMC4wODk4
NTBdIERSMDogMDAwMDAwMDAgRFIxOiAwMDAwMDAwMCBEUjI6IDAwMDAwMDAwIERSMzogMDAwMDAw
MDANClsgICAgMC4wOTA1NTddIERSNjogZmZmZTBmZjAgRFI3OiAwMDAwMDQwMA0KWyAgICAwLjA5
MDk5Ml0gS2VybmVsIHBhbmljIC0gbm90IHN5bmNpbmc6IEF0dGVtcHRlZCB0byBraWxsIHRoZSBp
ZGxlIHRhc2shDQoNCg0KUGF2ZWwNCg0KT24gOC8zMS8xOCA3OjI5IEFNLCBKaXJpIFNsYWJ5IHdy
b3RlOg0KPiBPbiAwOC8zMS8yMDE4LCAwMToyNiBQTSwgSmlyaSBTbGFieSB3cm90ZToNCj4+IE9u
IDA4LzMwLzIwMTgsIDA1OjQ1IFBNLCBQYXNoYSBUYXRhc2hpbiB3cm90ZToNCj4+PiBIaSBKaXJp
LA0KPj4+DQo+Pj4gSSBiZWxpZXZlIHRoaXMgYnVnIGlzIGZpeGVkIHdpdGggdGhpcyBjaGFuZ2U6
DQo+Pj4NCj4+PiBkMzlmOGZiNGI3Nzc2ZGNiMDllYzNiZjdhMzIxNTQ3MDgzMDc4ZWUzDQo+Pj4g
bW06IG1ha2UgREVGRVJSRURfU1RSVUNUX1BBR0VfSU5JVCBleHBsaWNpdGx5IGRlcGVuZCBvbiBT
UEFSU0VNRU0NCj4+DQo+PiBIaSwNCj4+DQo+PiBpdCBvbmx5IHNoaWZ0ZWQuIEVuYWJsaW5nIG9u
bHkgU1BBUlNFTUVNIHdvcmtzIGZpbmUsIGVuYWJsaW5nIGFsc28NCj4+IERFRkVSUkVEX1NUUlVD
VF9QQUdFX0lOSVQgZG9lc24ndCBldmVuIGJvb3Qg4oCTIGltbWVkaWF0ZWx5IHJlYm9vdHMNCj4+
IChjb25maWcgYXR0YWNoZWQpLg0KPiANCj4gV293LCBlYXJseXByaW50ayBpcyB1cCBhdCB0aGUg
bW9tZW50IG9mIGNyYXNoIGFscmVhZHk6DQo+IFsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24g
NC4xOS4wLXJjMS1wYWUgKGpzbGFieUBrdW5sdW4pIChnY2MgdmVyc2lvbg0KPiA0LjguNSAoU1VT
RSBMaW51eCkpICM0IFNNUCBQUkVFTVBUIEZyaSBBdWcgMzEgMTM6MTg6MzMgQ0VTVCAyMDE4DQo+
IFsgICAgMC4wMDAwMDBdIHg4Ni9mcHU6IHg4NyBGUFUgd2lsbCB1c2UgRlhTQVZFDQo+IFsgICAg
MC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNCj4gWyAgICAwLjAwMDAw
MF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWZiZmZd
IHVzYWJsZQ0KPiBbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMDlm
YzAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0NCj4gcmVzZXJ2ZWQNCj4gWyAgICAwLjAwMDAwMF0gQklP
Uy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDBmMDAwMC0weDAwMDAwMDAwMDAwZmZmZmZdDQo+IHJl
c2VydmVkDQo+IFsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAxMDAw
MDAtMHgwMDAwMDAwMDdjZmRmZmZmXSB1c2FibGUNCj4gWyAgICAwLjAwMDAwMF0gQklPUy1lODIw
OiBbbWVtIDB4MDAwMDAwMDA3Y2ZlMDAwMC0weDAwMDAwMDAwN2NmZmZmZmZdDQo+IHJlc2VydmVk
DQo+IFsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmVmZmMwMDAtMHgw
MDAwMDAwMGZlZmZmZmZmXQ0KPiByZXNlcnZlZA0KPiBbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6
IFttZW0gMHgwMDAwMDAwMGZmZmMwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0NCj4gcmVzZXJ2ZWQN
Cj4gWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW2Vhcmx5c2VyMF0gZW5hYmxlZA0KPiBbICAg
IDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNCj4gWyAg
ICAwLjAwMDAwMF0gU01CSU9TIDIuOCBwcmVzZW50Lg0KPiBbICAgIDAuMDAwMDAwXSBETUk6IFFF
TVUgU3RhbmRhcmQgUEMgKGk0NDBGWCArIFBJSVgsIDE5OTYpLCBCSU9TDQo+IDEuMC4wLXByZWJ1
aWx0LnFlbXUtcHJvamVjdC5vcmcgMDQvMDEvMjAxNA0KPiBbICAgIDAuMDAwMDAwXSBIeXBlcnZp
c29yIGRldGVjdGVkOiBLVk0NCj4gWyAgICAwLjAwMDAwMF0ga3ZtLWNsb2NrOiBVc2luZyBtc3Jz
IDRiNTY0ZDAxIGFuZCA0YjU2NGQwMA0KPiBbICAgIDAuMDAwMDAyXSBrdm0tY2xvY2s6IGNwdSAw
LCBtc3IgMWQxMmMwMDEsIHByaW1hcnkgY3B1IGNsb2NrDQo+IFsgICAgMC4wMDAwMDJdIGt2bS1j
bG9jazogdXNpbmcgc2NoZWQgb2Zmc2V0IG9mIDE1OTcxMTc5OTYgY3ljbGVzDQo+IFsgICAgMC4w
MDEzOTVdIGNsb2Nrc291cmNlOiBrdm0tY2xvY2s6IG1hc2s6IDB4ZmZmZmZmZmZmZmZmZmZmZg0K
PiBtYXhfY3ljbGVzOiAweDFjZDQyZTRkZmZiLCBtYXhfaWRsZV9uczogODgxNTkwNTkxNDgzIG5z
DQo+IFsgICAgMC4wMDYyNDVdIHRzYzogRGV0ZWN0ZWQgMjgwOC4wMDAgTUh6IHByb2Nlc3Nvcg0K
PiBbICAgIDAuMDEwMDU1XSBsYXN0X3BmbiA9IDB4N2NmZTAgbWF4X2FyY2hfcGZuID0gMHgxMDAw
MDAwDQo+IFsgICAgMC4wMTE0ODNdIHg4Ni9QQVQ6IFBBVCBub3Qgc3VwcG9ydGVkIGJ5IENQVS4N
Cj4gWyAgICAwLjAxMjU4MF0geDg2L1BBVDogQ29uZmlndXJhdGlvbiBbMC03XTogV0IgIFdUICBV
Qy0gVUMgIFdCICBXVCAgVUMtDQo+IFVDDQo+IFsgICAgMC4wMjA2NDRdIGZvdW5kIFNNUCBNUC10
YWJsZSBhdCBbbWVtIDB4MDAwZjVkMjAtMHgwMDBmNWQyZl0gbWFwcGVkDQo+IGF0IFsocHRydmFs
KV0NCj4gWyAgICAwLjAyMzUyOF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9yeSBjb3Jy
dXB0aW9uDQo+IFsgICAgMC4wMjUwNDddIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3VtIHZlcmlm
aWNhdGlvbiBkaXNhYmxlZA0KPiBbICAgIDAuMDI2NTgxXSBBQ1BJOiBSU0RQIDB4MDAwMDAwMDAw
MDBGNUI0MCAwMDAwMTQgKHYwMCBCT0NIUyApDQo+IFsgICAgMC4wMjgwMzFdIEFDUEk6IFJTRFQg
MHgwMDAwMDAwMDdDRkUxNTdDIDAwMDAzMCAodjAxIEJPQ0hTICBCWFBDUlNEVA0KPiAwMDAwMDAw
MSBCWFBDIDAwMDAwMDAxKQ0KPiBbICAgIDAuMDI5OTk2XSBBQ1BJOiBGQUNQIDB4MDAwMDAwMDA3
Q0ZFMTQ1OCAwMDAwNzQgKHYwMSBCT0NIUyAgQlhQQ0ZBQ1ANCj4gMDAwMDAwMDEgQlhQQyAwMDAw
MDAwMSkNCj4gWyAgICAwLjAzMjIzNF0gQUNQSTogRFNEVCAweDAwMDAwMDAwN0NGRTAwNDAgMDAx
NDE4ICh2MDEgQk9DSFMgIEJYUENEU0RUDQo+IDAwMDAwMDAxIEJYUEMgMDAwMDAwMDEpDQo+IFsg
ICAgMC4wMzQ2NjJdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMDdDRkUwMDAwIDAwMDA0MA0KPiBbICAg
IDAuMDM2MTI2XSBBQ1BJOiBBUElDIDB4MDAwMDAwMDA3Q0ZFMTRDQyAwMDAwNzggKHYwMSBCT0NI
UyAgQlhQQ0FQSUMNCj4gMDAwMDAwMDEgQlhQQyAwMDAwMDAwMSkNCj4gWyAgICAwLjAzODIzNV0g
QUNQSTogSFBFVCAweDAwMDAwMDAwN0NGRTE1NDQgMDAwMDM4ICh2MDEgQk9DSFMgIEJYUENIUEVU
DQo+IDAwMDAwMDAxIEJYUEMgMDAwMDAwMDEpDQo+IFsgICAgMC4wNDAzNzNdIE5vIE5VTUEgY29u
ZmlndXJhdGlvbiBmb3VuZA0KPiBbICAgIDAuMDQxNDA3XSBGYWtpbmcgYSBub2RlIGF0IFttZW0g
MHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDA3Y2ZkZmZmZl0NCj4gWyAgICAwLjA0MzMwNl0g
Tk9ERV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4MzY3ZmMwMDAtMHgzNjdmY2ZmZl0NCj4gWyAg
ICAwLjA0NDk1OF0gMTEyN01CIEhJR0hNRU0gYXZhaWxhYmxlLg0KPiBbICAgIDAuMDQ1OTQwXSA4
NzFNQiBMT1dNRU0gYXZhaWxhYmxlLg0KPiBbICAgIDAuMDQ2OTc4XSAgIG1hcHBlZCBsb3cgcmFt
OiAwIC0gMzY3ZmUwMDANCj4gWyAgICAwLjA0ODIwMF0gICBsb3cgcmFtOiAwIC0gMzY3ZmUwMDAN
Cj4gWyAgICAwLjA1MDgzMF0gWm9uZSByYW5nZXM6DQo+IFsgICAgMC4wNTE2MjVdICAgRE1BICAg
ICAgW21lbSAweDAwMDAwMDAwMDAwMDEwMDAtMHgwMDAwMDAwMDAwZmZmZmZmXQ0KPiBbICAgIDAu
MDUzMjk1XSAgIE5vcm1hbCAgIFttZW0gMHgwMDAwMDAwMDAxMDAwMDAwLTB4MDAwMDAwMDAzNjdm
ZGZmZl0NCj4gWyAgICAwLjA1NDkyMV0gICBIaWdoTWVtICBbbWVtIDB4MDAwMDAwMDAzNjdmZTAw
MC0weDAwMDAwMDAwN2NmZGZmZmZdDQo+IFsgICAgMC4wNTY0MDhdIE1vdmFibGUgem9uZSBzdGFy
dCBmb3IgZWFjaCBub2RlDQo+IFsgICAgMC4wNTc0NTJdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdl
cw0KPiBbICAgIDAuMDU4Mzc3XSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMTAwMC0w
eDAwMDAwMDAwMDAwOWVmZmZdDQo+IFsgICAgMC4wNTk5NDZdICAgbm9kZSAgIDA6IFttZW0gMHgw
MDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDA3Y2ZkZmZmZl0NCj4gWyAgICAwLjA2MTgyNV0gUmVz
ZXJ2ZWQgYnV0IHVuYXZhaWxhYmxlOiAxMjQxOCBwYWdlcw0KPiBbICAgIDAuMDYxODI4XSBJbml0
bWVtIHNldHVwIG5vZGUgMCBbbWVtDQo+IDB4MDAwMDAwMDAwMDAwMTAwMC0weDAwMDAwMDAwN2Nm
ZGZmZmZdDQo+IFsgICAgMC4wNzQyNTJdIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCj4gWyAg
ICAwLjA3NTYxNV0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg2MDgNCj4gWyAgICAwLjA3NjU3
NF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4ZmZdIGRmbCBkZmwgbGludFsweDFdKQ0KPiBb
ICAgIDAuMDc3OTk1XSBJT0FQSUNbMF06IGFwaWNfaWQgMCwgdmVyc2lvbiAxNywgYWRkcmVzcyAw
eGZlYzAwMDAwLCBHU0kNCj4gMC0yMw0KPiBbICAgIDAuMDc5NjEwXSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KPiBbICAgIDAuMDgxMTEx
XSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA1IGdsb2JhbF9pcnEgNSBoaWdoIGxl
dmVsKQ0KPiBbICAgIDAuMDgyNzg2XSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5
IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQ0KPiBbICAgIDAuMDg0Mjk3XSBBQ1BJOiBJTlRfU1JD
X09WUiAoYnVzIDAgYnVzX2lycSAxMCBnbG9iYWxfaXJxIDEwIGhpZ2ggbGV2ZWwpDQo+IFsgICAg
MC4wODU5MzNdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDExIGdsb2JhbF9pcnEg
MTEgaGlnaCBsZXZlbCkNCj4gWyAgICAwLjA4NzcyOV0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNN
UCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQo+IFsgICAgMC4wODkxMTldIEFDUEk6IEhQRVQg
aWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMA0KPiBbICAgIDAuMDkwMzUxXSBzbXBib290
OiBBbGxvd2luZyAxIENQVXMsIDAgaG90cGx1ZyBDUFVzDQo+IFsgICAgMC4wOTE1NjFdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXQ0KPiBb
ICAgIDAuMDkzMzYxXSBQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDAwOWYw
MDAtMHgwMDA5ZmZmZl0NCj4gWyAgICAwLjA5NjM4Ml0gUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1l
bW9yeTogW21lbSAweDAwMGEwMDAwLTB4MDAwZWZmZmZdDQo+IFsgICAgMC4wOTgxMzBdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgwMDBmMDAwMC0weDAwMGZmZmZmXQ0KPiBb
ICAgIDAuMDk5NzI5XSBbbWVtIDB4N2QwMDAwMDAtMHhmZWZmYmZmZl0gYXZhaWxhYmxlIGZvciBQ
Q0kgZGV2aWNlcw0KPiBbICAgIDAuMTAxMDM0XSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu
ZWwgb24gS1ZNDQo+IFsgICAgMC4xMDIwMzRdIGNsb2Nrc291cmNlOiByZWZpbmVkLWppZmZpZXM6
IG1hc2s6IDB4ZmZmZmZmZmYNCj4gbWF4X2N5Y2xlczogMHhmZmZmZmZmZiwgbWF4X2lkbGVfbnM6
IDc2NDU1MTk2MDAyMTE1NjggbnMNCj4gWyAgICAwLjEwNDIwN10gcmFuZG9tOiBnZXRfcmFuZG9t
X2J5dGVzIGNhbGxlZCBmcm9tDQo+IHN0YXJ0X2tlcm5lbCsweDc3LzB4NDdjIHdpdGggY3JuZ19p
bml0PTANCj4gWyAgICAwLjEwNTkxM10gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjY0IG5yX2NwdW1h
c2tfYml0czo2NCBucl9jcHVfaWRzOjENCj4gbnJfbm9kZV9pZHM6MQ0KPiBbICAgIDAuMTA3NTQ4
XSBwZXJjcHU6IEVtYmVkZGVkIDMxIHBhZ2VzL2NwdSBAKHB0cnZhbCkgczk0NjA0IHIwIGQzMjM3
Mg0KPiB1MTI2OTc2DQo+IFsgICAgMC4xMDkwMTldIEtWTSBzZXR1cCBhc3luYyBQRiBmb3IgY3B1
IDANCj4gWyAgICAwLjEwOTgyNV0ga3ZtLXN0ZWFsdGltZTogY3B1IDAsIG1zciAzNjdlNTMwMA0K
PiBbICAgIDAuMTEwNzU1XSBCdWlsdCAxIHpvbmVsaXN0cywgbW9iaWxpdHkgZ3JvdXBpbmcgb24u
ICBUb3RhbCBwYWdlczogNTA5OTA4DQo+IFsgICAgMC4xMTIxMTNdIFBvbGljeSB6b25lOiBIaWdo
TWVtDQo+IFsgICAgMC4xMTI3NTVdIEtlcm5lbCBjb21tYW5kIGxpbmU6IGVhcmx5cHJpbnRrPXNl
cmlhbA0KPiBbICAgIDAuMTEzNzczXSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAx
MzEwNzIgKG9yZGVyOiA3LCA1MjQyODgNCj4gYnl0ZXMpDQo+IFsgICAgMC4xMTU3ODhdIElub2Rl
LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA2LCAyNjIxNDQNCj4gYnl0
ZXMpDQo+IFsgICAgMC4xMTc0NjVdIEluaXRpYWxpemluZyBDUFUjMA0KPiBbICAgIDAuMTE4NTIy
XSBJbml0aWFsaXppbmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAzNjdmZTowMDA3Y2ZlMCkNCj4g
WyAgICAwLjE2MTE0MF0gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIg
ZGVyZWZlcmVuY2UgYXQNCj4gMDAwMDAwMjgNCj4gWyAgICAwLjE2MjY3MV0gKnBkcHQgPSAwMDAw
MDAwMDAwMDAwMDAwICpwZGUgPSBmMDAwZmY1M2YwMDBmZjUzDQo+IFsgICAgMC4xNjM4NTddIE9v
cHM6IDAwMDAgWyMxXSBQUkVFTVBUIFNNUCBQVEkNCj4gWyAgICAwLjE2NDg2Ml0gQ1BVOiAwIFBJ
RDogMCBDb21tOiBzd2FwcGVyIE5vdCB0YWludGVkIDQuMTkuMC1yYzEtcGFlICM0DQo+IG9wZW5T
VVNFIFR1bWJsZXdlZWQgKHVucmVsZWFzZWQpDQo+IFsgICAgMC4xNjcwNDFdIEhhcmR3YXJlIG5h
bWU6IFFFTVUgU3RhbmRhcmQgUEMgKGk0NDBGWCArIFBJSVgsIDE5OTYpLA0KPiBCSU9TIDEuMC4w
LXByZWJ1aWx0LnFlbXUtcHJvamVjdC5vcmcgMDQvMDEvMjAxNA0KPiBbICAgIDAuMTY5Mzg5XSBF
SVA6IGZyZWVfdW5yZWZfcGFnZV9wcmVwYXJlLnBhcnQuNzUrMHgyNi8weDUwDQo+IFsgICAgMC4x
NzAzMzddIENvZGU6IDAwIDAwIDAwIDAwIGU4IGU3IGE0IGU5IGZmIDg5IGQxIGMxIGVhIDExIDU1
IDhiIDE0DQo+IGQ1IDg0IGQyIDFjIGRkIGMxIGU5IDA3IDg5IGU1IDU2IDgxIGUxIGZjIDAzIDAw
IDAwIDUzIDg5IGNiIGMxIGViIDA1IDg5DQo+IGNlIDw4Yj4gMTQgOWEgODMgZTYgMWYgYjkgMWQg
MDAgMDAgMDAgMjkgZjEgZDMgZWEgODMgZTIgMDcgODkgNTAgMTAgYjgNCj4gWyAgICAwLjE3NDIw
NV0gRUFYOiBmNGNmYTAwMCBFQlg6IDAwMDAwMDBhIEVDWDogMDAwMDAxNTAgRURYOiAwMDAwMDAw
MA0KPiBbICAgIDAuMTc1NDIyXSBFU0k6IDAwMDAwMTUwIEVESTogMDBkODAwMDAgRUJQOiBkY2Yy
YmU1MCBFU1A6IGRjZjJiZTQ4DQo+IFsgICAgMC4xNzY3MjRdIERTOiAwMDdiIEVTOiAwMDdiIEZT
OiAwMGQ4IEdTOiAwMGUwIFNTOiAwMDY4IEVGTEFHUzogMDAyMTAwMDcNCj4gWyAgICAwLjE3ODA3
NV0gQ1IwOiA4MDA1MDAzMyBDUjI6IDAwMDAwMDI4IENSMzogMWQxMTgwMDAgQ1I0OiAwMDAwMDZi
MA0KPiBbICAgIDAuMTc5MzU0XSBEUjA6IDAwMDAwMDAwIERSMTogMDAwMDAwMDAgRFIyOiAwMDAw
MDAwMCBEUjM6IDAwMDAwMDAwDQo+IFsgICAgMC4xODA2MjldIERSNjogZmZmZTBmZjAgRFI3OiAw
MDAwMDQwMA0KPiBbICAgIDAuMTgxNDAwXSBDYWxsIFRyYWNlOg0KPiBbICAgIDAuMTgxOTA3XSAg
ZnJlZV91bnJlZl9wYWdlKzB4M2EvMHg5MA0KPiBbICAgIDAuMTgyNjQyXSAgX19mcmVlX3BhZ2Vz
KzB4MjUvMHgzMA0KPiBbICAgIDAuMTgzNzQ4XSAgZnJlZV9oaWdobWVtX3BhZ2UrMHgxZS8weDUw
DQo+IFsgICAgMC4xODQ1OTRdICBhZGRfaGlnaHBhZ2VzX3dpdGhfYWN0aXZlX3JlZ2lvbnMrMHgx
MjMvMHgxMjUNCj4gWyAgICAwLjE4NTgxM10gIHNldF9oaWdobWVtX3BhZ2VzX2luaXQrMHg4My8w
eDhkDQo+IFsgICAgMC4xODY4NDddICBtZW1faW5pdCsweDI2LzB4MjQwDQo+IFsgICAgMC4xODc1
OTBdICA/IHZwcmludGtfZnVuYysweDM4LzB4ZDANCj4gWyAgICAwLjE4ODQyN10gID8gaWR0X3Nl
dHVwX2Zyb21fdGFibGUuY29uc3Rwcm9wLjErMHg0NS8weDcwDQo+IFsgICAgMC4xODk2NjZdICA/
IHNldF9pbnRyX2dhdGUrMHgzOS8weDQwDQo+IFsgICAgMC4xOTA1NTFdICA/IGdlbmVyYWxfcHJv
dGVjdGlvbisweGMvMHhjDQo+IFsgICAgMC4xOTE4MThdICA/IHVwZGF0ZV9pbnRyX2dhdGUrMHgx
ZS8weDIwDQo+IFsgICAgMC4xOTI4MTddICA/IGt2bV9hcGZfdHJhcF9pbml0KzB4MTcvMHgxOQ0K
PiBbICAgIDAuMTkzODAwXSAgPyB0cmFwX2luaXQrMHg3Ny8weDdkDQo+IFsgICAgMC4xOTQ2NDRd
ICBzdGFydF9rZXJuZWwrMHgyMDMvMHg0N2MNCj4gWyAgICAwLjE5NTQ5MV0gID8gc2V0X2luaXRf
YXJnKzB4NTcvMHg1Nw0KPiBbICAgIDAuMTk2Mzg1XSAgaTM4Nl9zdGFydF9rZXJuZWwrMHgxNDMv
MHgxNDYNCj4gWyAgICAwLjE5NzM1MV0gIHN0YXJ0dXBfMzJfc21wKzB4MTY0LzB4MTY4DQo+IFsg
ICAgMC4xOTgyMzJdIE1vZHVsZXMgbGlua2VkIGluOg0KPiBbICAgIDAuMTk5MDcyXSBDUjI6IDAw
MDAwMDAwMDAwMDAwMjgNCj4gWyAgICAwLjE5OTk4M10gLS0tWyBlbmQgdHJhY2UgNjlmNGE4NjRj
OGJkOWJjZCBdLS0tDQo+IFsgICAgMC4yMDExOThdIEVJUDogZnJlZV91bnJlZl9wYWdlX3ByZXBh
cmUucGFydC43NSsweDI2LzB4NTANCj4gWyAgICAwLjIwMjYxMF0gQ29kZTogMDAgMDAgMDAgMDAg
ZTggZTcgYTQgZTkgZmYgODkgZDEgYzEgZWEgMTEgNTUgOGIgMTQNCj4gZDUgODQgZDIgMWMgZGQg
YzEgZTkgMDcgODkgZTUgNTYgODEgZTEgZmMgMDMgMDAgMDAgNTMgODkgY2IgYzEgZWIgMDUgODkN
Cj4gY2UgPDhiPiAxNCA5YSA4MyBlNiAxZiBiOSAxZCAwMCAwMCAwMCAyOSBmMSBkMyBlYSA4MyBl
MiAwNyA4OSA1MCAxMCBiOA0KPiBbICAgIDAuMjA2OTQyXSBFQVg6IGY0Y2ZhMDAwIEVCWDogMDAw
MDAwMGEgRUNYOiAwMDAwMDE1MCBFRFg6IDAwMDAwMDAwDQo+IFsgICAgMC4yMDgxNzddIEVTSTog
MDAwMDAxNTAgRURJOiAwMGQ4MDAwMCBFQlA6IGRjZjJiZTUwIEVTUDogZGQxMWZlZmMNCj4gWyAg
ICAwLjIwOTQzOF0gRFM6IDAwN2IgRVM6IDAwN2IgRlM6IDAwZDggR1M6IDAwZTAgU1M6IDAwNjgg
RUZMQUdTOiAwMDIxMDAwNw0KPiBbICAgIDAuMjEwODI2XSBDUjA6IDgwMDUwMDMzIENSMjogMDAw
MDAwMjggQ1IzOiAxZDExODAwMCBDUjQ6IDAwMDAwNmIwDQo+IFsgICAgMC4yMTIxNTVdIERSMDog
MDAwMDAwMDAgRFIxOiAwMDAwMDAwMCBEUjI6IDAwMDAwMDAwIERSMzogMDAwMDAwMDANCj4gWyAg
ICAwLjIxMzc1Ml0gRFI2OiBmZmZlMGZmMCBEUjc6IDAwMDAwNDAwDQo+IA0KPiANCj4+DQo+PiB0
aGFua3MsDQo+Pg0KPiANCj4g
^ permalink raw reply
* RE: [PATCH 0/7 v6] Support for fsl-mc bus and its devices in SMMU
From: Nipun Gupta @ 2018-08-31 11:57 UTC (permalink / raw)
To: robin.murphy@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
robh@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com,
gregkh@linuxfoundation.org, Laurentiu Tudor, bhelgaas@google.com,
hch@lst.de
Cc: joro@8bytes.org, m.szyprowski@samsung.com, shawnguo@kernel.org,
frowand.list@gmail.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
Bharat Bhushan, stuyoder@gmail.com, Leo Li
In-Reply-To: <1531135103-10699-1-git-send-email-nipun.gupta@nxp.com>
Hi Joerg/Robin,
Can you please let me know when these patches will be applied onto the tree=
.
Is there anything else pending from my side.
Thanks,
Nipun
> -----Original Message-----
> From: Nipun Gupta
> Sent: Monday, July 9, 2018 4:48 PM
> To: robin.murphy@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> robh@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com;
> gregkh@linuxfoundation.org; Laurentiu Tudor <laurentiu.tudor@nxp.com>;
> bhelgaas@google.com; hch@lst.de
> Cc: joro@8bytes.org; m.szyprowski@samsung.com; shawnguo@kernel.org;
> frowand.list@gmail.com; iommu@lists.linux-foundation.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; linux-
> pci@vger.kernel.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
> stuyoder@gmail.com; Leo Li <leoyang.li@nxp.com>; Nipun Gupta
> <nipun.gupta@nxp.com>
> Subject: [PATCH 0/7 v6] Support for fsl-mc bus and its devices in SMMU
>=20
> This patchset defines IOMMU DT binding for fsl-mc bus and adds
> support in SMMU for fsl-mc bus.
>=20
> The patch series is based on top of dma-mapping tree (for-next branch):
> http://git.infradead.org/users/hch/dma-mapping.git
>=20
> These patches
> - Define property 'iommu-map' for fsl-mc bus (patch 1)
> - Integrates the fsl-mc bus with the SMMU using this
> IOMMU binding (patch 2,3,4)
> - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
> - Updates the fsl-mc device node with iommu/dma related changes (patch =
7)
>=20
> Changes in v2:
> - use iommu-map property for fsl-mc bus
> - rebase over patchset https://patchwork.kernel.org/patch/10317337/
> and make corresponding changes for dma configuration of devices on
> fsl-mc bus
>=20
> Changes in v3:
> - move of_map_rid in drivers/of/address.c
>=20
> Changes in v4:
> - move of_map_rid in drivers/of/base.c
>=20
> Changes in v5:
> - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
> - add changelog text in patch 3/7 and patch 5/7
> - typo fix
>=20
> Changes in v6:
> - Updated fsl_mc_device_group() API to be more rational
> - Added dma-coherent property in the LS2 smmu device node
> - Minor fixes in the device-tree documentation
>=20
> Nipun Gupta (7):
> Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
> bus
> iommu/of: make of_pci_map_rid() available for other devices too
> iommu/of: support iommu configuration for fsl-mc devices
> iommu/arm-smmu: Add support for the fsl-mc bus
> bus: fsl-mc: support dma configure for devices on fsl-mc bus
> bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
> arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
>=20
> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 +-
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16 +++-
> drivers/iommu/arm-smmu.c | 7 ++
> drivers/iommu/iommu.c | 13 +++
> drivers/iommu/of_iommu.c | 25 ++++-
> drivers/of/base.c | 102 +++++++++++++++=
++++++
> drivers/of/irq.c | 5 +-
> drivers/pci/of.c | 101 ---------------=
-----
> include/linux/fsl/mc.h | 8 ++
> include/linux/iommu.h | 2 +
> include/linux/of.h | 11 +++
> include/linux/of_pci.h | 10 --
> 13 files changed, 224 insertions(+), 122 deletions(-)
>=20
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Jiri Slaby @ 2018-08-31 11:29 UTC (permalink / raw)
To: Pasha Tatashin
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <597f3f35-6aad-6ca1-ba03-b93444b1cb5f@suse.cz>
On 08/31/2018, 01:26 PM, Jiri Slaby wrote:
> On 08/30/2018, 05:45 PM, Pasha Tatashin wrote:
>> Hi Jiri,
>>
>> I believe this bug is fixed with this change:
>>
>> d39f8fb4b7776dcb09ec3bf7a321547083078ee3
>> mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
>
> Hi,
>
> it only shifted. Enabling only SPARSEMEM works fine, enabling also
> DEFERRED_STRUCT_PAGE_INIT doesn't even boot – immediately reboots
> (config attached).
Wow, earlyprintk is up at the moment of crash already:
[ 0.000000] Linux version 4.19.0-rc1-pae (jslaby@kunlun) (gcc version
4.8.5 (SUSE Linux)) #4 SMP PREEMPT Fri Aug 31 13:18:33 CEST 2018
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007cfdffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007cfe0000-0x000000007cffffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff]
reserved
[ 0.000000] bootconsole [earlyser0] enabled
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.0.0-prebuilt.qemu-project.org 04/01/2014
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000002] kvm-clock: cpu 0, msr 1d12c001, primary cpu clock
[ 0.000002] kvm-clock: using sched offset of 1597117996 cycles
[ 0.001395] clocksource: kvm-clock: mask: 0xffffffffffffffff
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.006245] tsc: Detected 2808.000 MHz processor
[ 0.010055] last_pfn = 0x7cfe0 max_arch_pfn = 0x1000000
[ 0.011483] x86/PAT: PAT not supported by CPU.
[ 0.012580] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC-
UC
[ 0.020644] found SMP MP-table at [mem 0x000f5d20-0x000f5d2f] mapped
at [(ptrval)]
[ 0.023528] Scanning 1 areas for low memory corruption
[ 0.025047] ACPI: Early table checksum verification disabled
[ 0.026581] ACPI: RSDP 0x00000000000F5B40 000014 (v00 BOCHS )
[ 0.028031] ACPI: RSDT 0x000000007CFE157C 000030 (v01 BOCHS BXPCRSDT
00000001 BXPC 00000001)
[ 0.029996] ACPI: FACP 0x000000007CFE1458 000074 (v01 BOCHS BXPCFACP
00000001 BXPC 00000001)
[ 0.032234] ACPI: DSDT 0x000000007CFE0040 001418 (v01 BOCHS BXPCDSDT
00000001 BXPC 00000001)
[ 0.034662] ACPI: FACS 0x000000007CFE0000 000040
[ 0.036126] ACPI: APIC 0x000000007CFE14CC 000078 (v01 BOCHS BXPCAPIC
00000001 BXPC 00000001)
[ 0.038235] ACPI: HPET 0x000000007CFE1544 000038 (v01 BOCHS BXPCHPET
00000001 BXPC 00000001)
[ 0.040373] No NUMA configuration found
[ 0.041407] Faking a node at [mem 0x0000000000000000-0x000000007cfdffff]
[ 0.043306] NODE_DATA(0) allocated [mem 0x367fc000-0x367fcfff]
[ 0.044958] 1127MB HIGHMEM available.
[ 0.045940] 871MB LOWMEM available.
[ 0.046978] mapped low ram: 0 - 367fe000
[ 0.048200] low ram: 0 - 367fe000
[ 0.050830] Zone ranges:
[ 0.051625] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.053295] Normal [mem 0x0000000001000000-0x00000000367fdfff]
[ 0.054921] HighMem [mem 0x00000000367fe000-0x000000007cfdffff]
[ 0.056408] Movable zone start for each node
[ 0.057452] Early memory node ranges
[ 0.058377] node 0: [mem 0x0000000000001000-0x000000000009efff]
[ 0.059946] node 0: [mem 0x0000000000100000-0x000000007cfdffff]
[ 0.061825] Reserved but unavailable: 12418 pages
[ 0.061828] Initmem setup node 0 [mem
0x0000000000001000-0x000000007cfdffff]
[ 0.074252] Using APIC driver default
[ 0.075615] ACPI: PM-Timer IO Port: 0x608
[ 0.076574] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[ 0.077995] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI
0-23
[ 0.079610] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.081111] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[ 0.082786] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.084297] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[ 0.085933] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[ 0.087729] Using ACPI (MADT) for SMP configuration information
[ 0.089119] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.090351] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.091561] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.093361] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[ 0.096382] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]
[ 0.098130] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[ 0.099729] [mem 0x7d000000-0xfeffbfff] available for PCI devices
[ 0.101034] Booting paravirtualized kernel on KVM
[ 0.102034] clocksource: refined-jiffies: mask: 0xffffffff
max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.104207] random: get_random_bytes called from
start_kernel+0x77/0x47c with crng_init=0
[ 0.105913] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1
nr_node_ids:1
[ 0.107548] percpu: Embedded 31 pages/cpu @(ptrval) s94604 r0 d32372
u126976
[ 0.109019] KVM setup async PF for cpu 0
[ 0.109825] kvm-stealtime: cpu 0, msr 367e5300
[ 0.110755] Built 1 zonelists, mobility grouping on. Total pages: 509908
[ 0.112113] Policy zone: HighMem
[ 0.112755] Kernel command line: earlyprintk=serial
[ 0.113773] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[ 0.115788] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[ 0.117465] Initializing CPU#0
[ 0.118522] Initializing HighMem for node 0 (000367fe:0007cfe0)
[ 0.161140] BUG: unable to handle kernel NULL pointer dereference at
00000028
[ 0.162671] *pdpt = 0000000000000000 *pde = f000ff53f000ff53
[ 0.163857] Oops: 0000 [#1] PREEMPT SMP PTI
[ 0.164862] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1-pae #4
openSUSE Tumbleweed (unreleased)
[ 0.167041] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[ 0.169389] EIP: free_unref_page_prepare.part.75+0x26/0x50
[ 0.170337] Code: 00 00 00 00 e8 e7 a4 e9 ff 89 d1 c1 ea 11 55 8b 14
d5 84 d2 1c dd c1 e9 07 89 e5 56 81 e1 fc 03 00 00 53 89 cb c1 eb 05 89
ce <8b> 14 9a 83 e6 1f b9 1d 00 00 00 29 f1 d3 ea 83 e2 07 89 50 10 b8
[ 0.174205] EAX: f4cfa000 EBX: 0000000a ECX: 00000150 EDX: 00000000
[ 0.175422] ESI: 00000150 EDI: 00d80000 EBP: dcf2be50 ESP: dcf2be48
[ 0.176724] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210007
[ 0.178075] CR0: 80050033 CR2: 00000028 CR3: 1d118000 CR4: 000006b0
[ 0.179354] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 0.180629] DR6: fffe0ff0 DR7: 00000400
[ 0.181400] Call Trace:
[ 0.181907] free_unref_page+0x3a/0x90
[ 0.182642] __free_pages+0x25/0x30
[ 0.183748] free_highmem_page+0x1e/0x50
[ 0.184594] add_highpages_with_active_regions+0x123/0x125
[ 0.185813] set_highmem_pages_init+0x83/0x8d
[ 0.186847] mem_init+0x26/0x240
[ 0.187590] ? vprintk_func+0x38/0xd0
[ 0.188427] ? idt_setup_from_table.constprop.1+0x45/0x70
[ 0.189666] ? set_intr_gate+0x39/0x40
[ 0.190551] ? general_protection+0xc/0xc
[ 0.191818] ? update_intr_gate+0x1e/0x20
[ 0.192817] ? kvm_apf_trap_init+0x17/0x19
[ 0.193800] ? trap_init+0x77/0x7d
[ 0.194644] start_kernel+0x203/0x47c
[ 0.195491] ? set_init_arg+0x57/0x57
[ 0.196385] i386_start_kernel+0x143/0x146
[ 0.197351] startup_32_smp+0x164/0x168
[ 0.198232] Modules linked in:
[ 0.199072] CR2: 0000000000000028
[ 0.199983] ---[ end trace 69f4a864c8bd9bcd ]---
[ 0.201198] EIP: free_unref_page_prepare.part.75+0x26/0x50
[ 0.202610] Code: 00 00 00 00 e8 e7 a4 e9 ff 89 d1 c1 ea 11 55 8b 14
d5 84 d2 1c dd c1 e9 07 89 e5 56 81 e1 fc 03 00 00 53 89 cb c1 eb 05 89
ce <8b> 14 9a 83 e6 1f b9 1d 00 00 00 29 f1 d3 ea 83 e2 07 89 50 10 b8
[ 0.206942] EAX: f4cfa000 EBX: 0000000a ECX: 00000150 EDX: 00000000
[ 0.208177] ESI: 00000150 EDI: 00d80000 EBP: dcf2be50 ESP: dd11fefc
[ 0.209438] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210007
[ 0.210826] CR0: 80050033 CR2: 00000028 CR3: 1d118000 CR4: 000006b0
[ 0.212155] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 0.213752] DR6: fffe0ff0 DR7: 00000400
>
> thanks,
>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Peter Zijlstra @ 2018-08-31 11:26 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180831111253.GJ24124@hirez.programming.kicks-ass.net>
On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> NAK, not until you've fixed every cpu_to_node() user in the kernel to
> deal with that mask changing.
Also, what happens if userspace reads that information; uses libnuma and
then you go and shift the world underneath their feet?
> This is absolutely insane.
^ permalink raw reply
* Re: [PATCH] sched/topology: Use Identity node only if required
From: Srikar Dronamraju @ 2018-08-31 11:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Andre Wild, Benjamin Herrenschmidt
In-Reply-To: <20180831104115.GH24124@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> [2018-08-31 12:41:15]:
> On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
>
> > At boot: Before topology update.
>
> How does that work; you do SMP bringup _before_ you know the topology !?
>
If you look at the other mail that I sent, the system boots to its regular
state with a certain topology. The hypervisor might detect and push topology
updates after the system has been booted and initialized. This topology
update can happen much much later after boot. We boot with a particular
topology and a later point of time, the topology update event occurs.
> > After topology update.
> >
> > For CPU 0
> > domain-0: span=0-7 level=SMT
> > groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 6:{ span=6 }, 7:{ span=7 }
> > domain-1: span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 level=DIE
> > groups: 0:{ span=0-7 cap=8192 }, 32:{ span=32-39 cap=8192 }, 64:{ span=64-71 cap=8192 }, 96:{ span=96-103 cap=8192 }, 128:{ span=128-135 cap=8192 }, 160:{ span=160-167 cap=8192 }, 192:{ span=192-199 cap=8192 }, 224:{ span=224-231 cap=8192 }, 256:{ span=256-263 cap=8192 }, 288:{ span=288-295 cap=8192 }
> > domain-2: span=0-303 level=NODE
> > groups: 0:{ span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 cap=81920 }, 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
> >
> > For CPU 9
> > domain-0: span=8-15 level=SMT
> > groups: 9:{ span=9 }, 10:{ span=10 }, 11:{ span=11 }, 12:{ span=12 }, 13:{ span=13 }, 14:{ span=14 }, 15:{ span=15 }, 8:{ span=8 }
> > domain-1: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=DIE
> > groups: 8:{ span=8-15 cap=8192 }, 40:{ span=40-47 cap=8192 }, 72:{ span=72-79 cap=8192 }, 104:{ span=104-111 cap=8192 }, 136:{ span=136-143 cap=8192 }, 168:{ span=168-175 cap=8192 }, 200:{ span=200-207 cap=8192 }, 232:{ span=232-239 cap=8192 }, 264:{ span=264-271 cap=8192 }, 296:{ span=296-303 cap=8192 }
> > domain-2: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=NODE
> > groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }
> > domain-3: span=0-303 level=NUMA
> > groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
> > ERROR: groups don't span domain->span
>
> This is all very confused... and does not include the error we saw
> earlier.
>
> CPU 0 has: SMT, DIE, NODE
> CPU 8 has: SMT, DIE, NODE, NUMA
>
This was the same in my previous posting too. Before the topology update
happened, all the cpus would be in SMT, DIE. The topology updates can be
disabled using a kernel parameter topology_updates=off. Its documented under
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html as
topology_updates= [KNL, PPC, NUMA] Format: {off} Specify if the kernel
should ignore (off) topology updates sent by the hypervisor to this
LPAR.
and is not something new in powerpc.
> Something is completely buggered in your topology setup.
>
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Jiri Slaby @ 2018-08-31 11:26 UTC (permalink / raw)
To: Pasha Tatashin
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <87516e50-a17c-6c80-e9b5-ba68eda9ce33@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
On 08/30/2018, 05:45 PM, Pasha Tatashin wrote:
> Hi Jiri,
>
> I believe this bug is fixed with this change:
>
> d39f8fb4b7776dcb09ec3bf7a321547083078ee3
> mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
Hi,
it only shifted. Enabling only SPARSEMEM works fine, enabling also
DEFERRED_STRUCT_PAGE_INIT doesn't even boot – immediately reboots
(config attached).
thanks,
--
js
suse labs
[-- Attachment #2: .config --]
[-- Type: application/x-config, Size: 206264 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Peter Zijlstra @ 2018-08-31 11:12 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180831102724.GB8437@linux.vnet.ibm.com>
On Fri, Aug 31, 2018 at 03:27:24AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@infradead.org> [2018-08-29 10:02:19]:
> Powerpc lpars running on Phyp have 2 modes. Dedicated and shared.
>
> Dedicated lpars are similar to kvm guest with vcpupin.
Like i know what that means... I'm not big on virt. I suppose you're
saying it has a fixed virt to phys mapping.
> Shared lpars are similar to kvm guest without any pinning. When running
> shared lpar mode, Phyp allows overcommitting. Now if more lpars are
> created/destroyed, Phyp will internally move / consolidate the cores. The
> objective is similar to what autonuma tries achieves on the host but with a
> different approach (consolidating to optimal nodes to achieve the best
> possible output). This would mean that the actual underlying cpus/node
> mapping has changed.
AFAIK Linux can _not_ handle cpu:node relations changing. And I'm pretty
sure I told you that before.
> Phyp will propogate upwards an event to the lpar. The
> lpar / os can choose to ignore or act on the same.
>
> We have found that acting on the event will provide upto 40% improvement
> over ignoring the event. Acting on the event would mean moving the cpu from
> one node to the other, and topology_work_fn exactly does that.
How? Last time I checked there was a ton of code that relies on
cpu_to_node() not changing during the runtime of the kernel.
Stuff like the per-cpu memory allocations are done using the boot time
cpu_to_node() map for instance. Similarly, kthread creation uses the
cpu_to_node() map at the time of creation.
A lot of stuff is not re-evaluated. If you're dynamically changing the
node map, you're in for a world of hurt.
> In the case where we didn't have the NUMA sched domain, we would build the
> independent (aka overlap) sched_groups. With NUMA sched domain
> introduction, we try to reuse sched_groups (aka non-overlay). This results
> in the above, which I thought I tried to explain in
> https://lwn.net/ml/linux-kernel/20180810164533.GB42350@linux.vnet.ibm.com
That email was a ton of confusion; you show an error and you don't
explain how you get there.
> In the typical case above, lets take 2 node, 8 core each having SMT 8
> threads. Initially all the 8 cores might come from node 0. Hence
> sched_domains_numa_masks[NODE][node1] and
> sched_domains_numa_mask[NUMA][node1] is set at sched_init_numa will have
> blank cpumasks.
>
> Let say Phyp decides to move some of the load to another node, node 1, which
> till now has 0 cpus. Hence we will see
>
> "BUG: arch topology borken \n the DIE domain not a subset of the NODE
> domain" which is probably okay. This problem is even present even before
> NODE domain was created and systems still booted and ran.
No that is _NOT_ OKAY. The fact that it boots and runs just means we
cope with it, but it violates a base assumption when building domains.
> However with the introduction of NODE sched_domain,
> init_sched_groups_capacity() gets called for non-overlay sched_domains which
> gets us into even worse problems. Here we will end up in a situation where
> sgA->sgB->sgC-sgD->sgA gets converted into sgA->sgB->sgC->sgB which ends up
> creating cpu stalls.
>
> So the request is to expose the sched_domains_numa_masks_set /
> sched_domains_numa_masks_clear to arch, so that on topology update i.e event
> from phyp, arch set the mask correctly. The scheduler seems to take care of
> everything else.
NAK, not until you've fixed every cpu_to_node() user in the kernel to
deal with that mask changing.
This is absolutely insane.
^ permalink raw reply
* Re: [PATCH] sched/topology: Use Identity node only if required
From: Peter Zijlstra @ 2018-08-31 10:41 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Andre Wild, Benjamin Herrenschmidt
In-Reply-To: <20180831102248.GA8437@linux.vnet.ibm.com>
On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
> At boot: Before topology update.
How does that work; you do SMP bringup _before_ you know the topology !?
> After topology update.
>
> For CPU 0
> domain-0: span=0-7 level=SMT
> groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 6:{ span=6 }, 7:{ span=7 }
> domain-1: span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 level=DIE
> groups: 0:{ span=0-7 cap=8192 }, 32:{ span=32-39 cap=8192 }, 64:{ span=64-71 cap=8192 }, 96:{ span=96-103 cap=8192 }, 128:{ span=128-135 cap=8192 }, 160:{ span=160-167 cap=8192 }, 192:{ span=192-199 cap=8192 }, 224:{ span=224-231 cap=8192 }, 256:{ span=256-263 cap=8192 }, 288:{ span=288-295 cap=8192 }
> domain-2: span=0-303 level=NODE
> groups: 0:{ span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 cap=81920 }, 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
>
> For CPU 1
> domain-0: span=0-7 level=SMT
> groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 6:{ span=6 }, 7:{ span=7 }, 0:{ span=0 }
> domain-1: span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 level=DIE
> groups: 0:{ span=0-7 cap=8192 }, 32:{ span=32-39 cap=8192 }, 64:{ span=64-71 cap=8192 }, 96:{ span=96-103 cap=8192 }, 128:{ span=128-135 cap=8192 }, 160:{ span=160-167 cap=8192 }, 192:{ span=192-199 cap=8192 }, 224:{ span=224-231 cap=8192 }, 256:{ span=256-263 cap=8192 }, 288:{ span=288-295 cap=8192 }
> domain-2: span=0-303 level=NODE
> groups: 0:{ span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 cap=81920 }, 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
>
>
> For CPU 8
> domain-0: span=8-15 level=SMT
> groups: 8:{ span=8 }, 9:{ span=9 }, 10:{ span=10 }, 11:{ span=11 }, 12:{ span=12 }, 13:{ span=13 }, 14:{ span=14 }, 15:{ span=15 }
> domain-1: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=DIE
> groups: 8:{ span=8-15 cap=8192 }, 40:{ span=40-47 cap=8192 }, 72:{ span=72-79 cap=8192 }, 104:{ span=104-111 cap=8192 }, 136:{ span=136-143 cap=8192 }, 168:{ span=168-175 cap=8192 }, 200:{ span=200-207 cap=8192 }, 232:{ span=232-239 cap=8192 }, 264:{ span=264-271 cap=8192 }, 296:{ span=296-303 cap=8192 }
> domain-2: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=NODE
> groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }
> domain-3: span=0-303 level=NUMA
> groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
> ERROR: groups don't span domain->span
>
> For CPU 9
> domain-0: span=8-15 level=SMT
> groups: 9:{ span=9 }, 10:{ span=10 }, 11:{ span=11 }, 12:{ span=12 }, 13:{ span=13 }, 14:{ span=14 }, 15:{ span=15 }, 8:{ span=8 }
> domain-1: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=DIE
> groups: 8:{ span=8-15 cap=8192 }, 40:{ span=40-47 cap=8192 }, 72:{ span=72-79 cap=8192 }, 104:{ span=104-111 cap=8192 }, 136:{ span=136-143 cap=8192 }, 168:{ span=168-175 cap=8192 }, 200:{ span=200-207 cap=8192 }, 232:{ span=232-239 cap=8192 }, 264:{ span=264-271 cap=8192 }, 296:{ span=296-303 cap=8192 }
> domain-2: span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 level=NODE
> groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }
> domain-3: span=0-303 level=NUMA
> groups: 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
> ERROR: groups don't span domain->span
This is all very confused... and does not include the error we saw
earlier.
CPU 0 has: SMT, DIE, NODE
CPU 8 has: SMT, DIE, NODE, NUMA
Something is completely buggered in your topology setup.
^ permalink raw reply
* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Srikar Dronamraju @ 2018-08-31 10:27 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20180829080219.GN24124@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> [2018-08-29 10:02:19]:
> On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> > With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an new numa level. However on shared
> > lpars like powerpc, this extra sched domain creation can lead to
> > repeated rcu stalls, sometimes even causing unresponsive systems on
> > boot. On such stalls, it was noticed that init_sched_groups_capacity()
> > (sg != sd->groups is always true).
> >
> > INFO: rcu_sched self-detected stall on CPU
> > 1-....: (240039 ticks this GP) idle=c32/1/4611686018427387906 softirq=782/782 fqs=80012
> > (t=240039 jiffies g=6272 c=6271 q=263040)
> > NMI backtrace for cpu 1
>
> > --- interrupt: 901 at __bitmap_weight+0x70/0x100
> > LR = __bitmap_weight+0x78/0x100
> > [c00000832132f9b0] [c0000000009bb738] __func__.61127+0x0/0x20 (unreliable)
> > [c00000832132fa00] [c00000000016c178] build_sched_domains+0xf98/0x13f0
> > [c00000832132fb30] [c00000000016d73c] partition_sched_domains+0x26c/0x440
> > [c00000832132fc20] [c0000000001ee284] rebuild_sched_domains_locked+0x64/0x80
> > [c00000832132fc50] [c0000000001f11ec] rebuild_sched_domains+0x3c/0x60
> > [c00000832132fc80] [c00000000007e1c4] topology_work_fn+0x24/0x40
> > [c00000832132fca0] [c000000000126704] process_one_work+0x1a4/0x470
> > [c00000832132fd30] [c000000000126a68] worker_thread+0x98/0x540
> > [c00000832132fdc0] [c00000000012f078] kthread+0x168/0x1b0
> > [c00000832132fe30] [c00000000000b65c]
> > ret_from_kernel_thread+0x5c/0x80
> >
> > Similar problem was earlier also reported at
> > https://lwn.net/ml/linux-kernel/20180512100233.GB3738@osiris/
> >
> > Allow arch to set and clear masks corresponding to numa sched domain.
>
> What this Changelog fails to do is explain the problem and motivate why
> this is the right solution.
>
> As-is, this reads like, something's buggered, I changed this random thing
> and it now works.
>
> So what is causing that domain construction error?
>
Powerpc lpars running on Phyp have 2 modes. Dedicated and shared.
Dedicated lpars are similar to kvm guest with vcpupin.
Shared lpars are similar to kvm guest without any pinning. When running
shared lpar mode, Phyp allows overcommitting. Now if more lpars are
created/destroyed, Phyp will internally move / consolidate the cores. The
objective is similar to what autonuma tries achieves on the host but with a
different approach (consolidating to optimal nodes to achieve the best
possible output). This would mean that the actual underlying cpus/node
mapping has changed. Phyp will propogate upwards an event to the lpar. The
lpar / os can choose to ignore or act on the same.
We have found that acting on the event will provide upto 40% improvement
over ignoring the event. Acting on the event would mean moving the cpu from
one node to the other, and topology_work_fn exactly does that.
In the case where we didn't have the NUMA sched domain, we would build the
independent (aka overlap) sched_groups. With NUMA sched domain
introduction, we try to reuse sched_groups (aka non-overlay). This results
in the above, which I thought I tried to explain in
https://lwn.net/ml/linux-kernel/20180810164533.GB42350@linux.vnet.ibm.com
In the typical case above, lets take 2 node, 8 core each having SMT 8
threads. Initially all the 8 cores might come from node 0. Hence
sched_domains_numa_masks[NODE][node1] and
sched_domains_numa_mask[NUMA][node1] is set at sched_init_numa will have
blank cpumasks.
Let say Phyp decides to move some of the load to another node, node 1, which
till now has 0 cpus. Hence we will see
"BUG: arch topology borken \n the DIE domain not a subset of the NODE
domain" which is probably okay. This problem is even present even before
NODE domain was created and systems still booted and ran.
However with the introduction of NODE sched_domain,
init_sched_groups_capacity() gets called for non-overlay sched_domains which
gets us into even worse problems. Here we will end up in a situation where
sgA->sgB->sgC-sgD->sgA gets converted into sgA->sgB->sgC->sgB which ends up
creating cpu stalls.
So the request is to expose the sched_domains_numa_masks_set /
sched_domains_numa_masks_clear to arch, so that on topology update i.e event
from phyp, arch set the mask correctly. The scheduler seems to take care of
everything else.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH] sched/topology: Use Identity node only if required
From: Srikar Dronamraju @ 2018-08-31 10:22 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
linuxppc-dev, Andre Wild, Benjamin Herrenschmidt
In-Reply-To: <20180829084348.GO24124@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> [2018-08-29 10:43:48]:
> On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
>=20
> > ....
> > CPU302 attaching NULL sched-domain.
> > CPU303 attaching NULL sched-domain.
> > BUG: arch topology borken
> > the DIE domain not a subset of the NODE domain
>=20
> ^^^^^ CLUE!!
>=20
> but nowhere did you show what it thinks the DIE mask is.
>=20
> > CPU0 attaching sched-domain(s):
> > domain-2: sdA, span=3D0-303 level=3DNODE
> > groups: sg=3DsgL 0:{ span=3D0-7,32-39,64-71,96-103,128-135,160-167,=
192-199,224-231,256-263,288-295 cap=3D81920 }, sgM 8:{ span=3D8-15,40-47,72=
-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=3D81920 }, =
sdN 16:{ span=3D16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,2=
72-279 cap=3D73728 }, sgO 24:{ span=3D24-31,56-63,88-95,120-127,152-159,184=
-191,216-223,248-255,280-287 cap=3D73728 }
> > CPU1 attaching sched-domain(s):
> > domain-2: sdB, span=3D0-303 level=3DNODE
> > [ 367.739387] groups: sg=3DsgL 0:{ span=3D0-7,32-39,64-71,96-103,1=
28-135,160-167,192-199,224-231,256-263,288-295 cap=3D81920 }, sgM 8:{ span=
=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303=
cap=3D81920 }, sdN 16:{ span=3D16-23,48-55,80-87,112-119,144-151,176-183,2=
08-215,240-247,272-279 cap=3D73728 }, sgO 24:{ span=3D24-31,56-63,88-95,120=
-127,152-159,184-191,216-223,248-255,280-287 cap=3D73728 }
>=20
> You forgot to provide the rest of it... what's domain-[01] look like?
At boot: Before topology update.
For CPU 0=20
domain-0: span=3D0-7 level=3DSMT
groups: 0:{ span=3D0 }, 1:{ span=3D1 }, 2:{ span=3D2 }, 3:{ span=3D3 }, 4:=
{ span=3D4 }, 5:{ span=3D5 }, 6:{ span=3D6 }, 7:{ span=3D7 }
domain-1: span=3D0-303 level=3DDIE
groups: 0:{ span=3D0-7 cap=3D8192 }, 8:{ span=3D8-15 cap=3D8192 }, 16:{ s=
pan=3D16-23 cap=3D8192 }, 24:{ span=3D24-31 cap=3D8192 }, 32:{ span=3D32-39=
cap=3D8192 }, 40:{ span=3D40-47 cap=3D8192 }, 48:{ span=3D48-55 cap=3D8192=
}, 56:{ span=3D56-63 cap=3D8192 }, 64:{ span=3D64-71 cap=3D8192 }, 72:{ sp=
an=3D72-79 cap=3D8192 }, 80:{ span=3D80-87 cap=3D8192 }, 88:{ span=3D88-95 =
cap=3D8192 }, 96:{ span=3D96-103 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8=
192 }, 112:{ span=3D112-119 cap=3D8192 }, 120:{ span=3D120-127 cap=3D8192 }=
, 128:{ span=3D128-135 cap=3D8192 }, 136:{ span=3D136-143 cap=3D8192 }, 144=
:{ span=3D144-151 cap=3D8192 }, 152:{ span=3D152-159 cap=3D8192 }, 160:{ sp=
an=3D160-167 cap=3D8192 }, 168:{ span=3D168-175 cap=3D8192 }, 176:{ span=3D=
176-183 cap=3D8192 }, 184:{ span=3D184-191 cap=3D8192 }, 192:{ span=3D192-1=
99 cap=3D8192 }, 200:{ span=3D200-207 cap=3D8192 }, 208:{ span=3D208-215 ca=
p=3D8192 }, 216:{ span=3D216-223 cap=3D8192 }, 224:{ span=3D224-231 cap=3D8=
192 }, 232:{ span=3D232-239 cap=3D8192 }, 240:{ span=3D240-247 cap=3D8192 }=
, 248:{ span=3D248-255 cap=3D8192 }, 256:{ span=3D256-263 cap=3D8192 }, 264=
:{ span=3D264-271 cap=3D8192 }, 272:{ span=3D272-279 cap=3D8192 }, 280:{ sp=
an=3D280-287 cap=3D8192 }, 288:{ span=3D288-295 cap=3D8192 }, 296:{ span=3D=
296-303 cap=3D8192 }
For CPU 1=20
domain-0: span=3D0-7 level=3DSMT
groups: 1:{ span=3D1 }, 2:{ span=3D2 }, 3:{ span=3D3 }, 4:{ span=3D4 }, 5:=
{ span=3D5 }, 6:{ span=3D6 }, 7:{ span=3D7 }, 0:{ span=3D0 }
domain-1: span=3D0-303 level=3DDIE
groups: 0:{ span=3D0-7 cap=3D8192 }, 8:{ span=3D8-15 cap=3D8192 }, 16:{ s=
pan=3D16-23 cap=3D8192 }, 24:{ span=3D24-31 cap=3D8192 }, 32:{ span=3D32-39=
cap=3D8192 }, 40:{ span=3D40-47 cap=3D8192 }, 48:{ span=3D48-55 cap=3D8192=
}, 56:{ span=3D56-63 cap=3D8192 }, 64:{ span=3D64-71 cap=3D8192 }, 72:{ sp=
an=3D72-79 cap=3D8192 }, 80:{ span=3D80-87 cap=3D8192 }, 88:{ span=3D88-95 =
cap=3D8192 }, 96:{ span=3D96-103 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8=
192 }, 112:{ span=3D112-119 cap=3D8192 }, 120:{ span=3D120-127 cap=3D8192 }=
, 128:{ span=3D128-135 cap=3D8192 }, 136:{ span=3D136-143 cap=3D8192 }, 144=
:{ span=3D144-151 cap=3D8192 }, 152:{ span=3D152-159 cap=3D8192 }, 160:{ sp=
an=3D160-167 cap=3D8192 }, 168:{ span=3D168-175 cap=3D8192 }, 176:{ span=3D=
176-183 cap=3D8192 }, 184:{ span=3D184-191 cap=3D8192 }, 192:{ span=3D192-1=
99 cap=3D8192 }, 200:{ span=3D200-207 cap=3D8192 }, 208:{ span=3D208-215 ca=
p=3D8192}, 216:{ span=3D216-223 cap=3D8192 }, 224:{ span=3D224-231 cap=3D81=
92 }, 232:{ span=3D232-239 cap=3D8192 }, 240:{ span=3D240-247 cap=3D8192 },=
248:{ span=3D248-255 cap=3D8192 }, 256:{ span=3D256-263 cap=3D8192 }, 264:=
{ span=3D264-271 cap=3D8192 }, 272:{ span=3D272-279 cap=3D8192 }, 280:{ spa=
n=3D280-287 cap=3D8192 }, 288:{ span=3D288-295 cap=3D8192 }, 296:{ span=3D2=
96-303 cap=3D8192 }
For CPU 8
domain-0: span=3D8-15 level=3DSMT
groups: 8:{ span=3D8 }, 9:{ span=3D9 }, 10:{ span=3D10 }, 11:{ span=3D11 }=
, 12:{ span=3D12 }, 13:{ span=3D13 }, 14:{ span=3D14 }, 15:{ span=3D15 }
domain-1: span=3D0-303 level=3DDIE
groups: 8:{ span=3D8-15 cap=3D8192 }, 16:{ span=3D16-23 cap=3D8192 }, 24:=
{ span=3D24-31 cap=3D8192 }, 32:{ span=3D32-39 cap=3D8192 }, 40:{ span=3D40=
-47 cap=3D8192 }, 48:{ span=3D48-55 cap=3D8192 }, 56:{ span=3D56-63 cap=3D8=
192 }, 64:{ span=3D64-71 cap=3D8192 }, 72:{ span=3D72-79 cap=3D8192 }, 80:{=
span=3D80-87 cap=3D8192 }, 88:{ span=3D88-95 cap=3D8192 }, 96:{ span=3D96-=
103 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8192 }, 112:{ span=3D112-119 c=
ap=3D8192 }, 120:{ span=3D120-127 cap=3D8192 }, 128:{ span=3D128-135 cap=3D=
8192 }, 136:{ span=3D136-143 cap=3D8192 }, 144:{ span=3D144-151 cap=3D8192 =
}, 152:{ span=3D152-159 cap=3D8192 }, 160:{ span=3D160-167 cap=3D8192 }, 16=
8:{ span=3D168-175 cap=3D8192 }, 176:{ span=3D176-183 cap=3D8192 }, 184:{ s=
pan=3D184-191 cap=3D8192 }, 192:{ span=3D192-199 cap=3D8192 }, 200:{ span=
=3D200-207 cap=3D8192 }, 208:{ span=3D208-215 cap=3D8192 }, 216:{ span=3D21=
6-223 cap=3D8192 }, 224:{ span=3D224-231 cap=3D8192 }, 232:{ span=3D232-239=
cap=3D8192 }, 240:{ span=3D240-247 cap=3D8192 }, 248:{ span=3D248-255 cap=
=3D8192 }, 256:{ span=3D256-263 cap=3D8192 }, 264:{ span=3D264-271 cap=3D81=
92 }, 272:{ span=3D272-279 cap=3D8192 }, 280:{ span=3D280-287 cap=3D8192 },=
288:{ span=3D288-295 cap=3D8192 }, 296:{ span=3D296-303 cap=3D8192 }, 0:{ =
span=3D0-7 cap=3D8192 }
For CPU 9=20
domain-0: span=3D8-15 level=3DSMT
groups: 9:{ span=3D9 }, 10:{ span=3D10 }, 11:{ span=3D11 }, 12:{ span=3D12=
}, 13:{ span=3D13 }, 14:{ span=3D14 }, 15:{ span=3D15 }, 8:{ span=3D8 }
domain-1: span=3D0-303 level=3DDIE
groups: 8:{ span=3D8-15 cap=3D8192 }, 16:{ span=3D16-23 cap=3D8192 }, 24:=
{ span=3D24-31 cap=3D8192 }, 32:{ span=3D32-39 cap=3D8192 }, 40:{ span=3D40=
-47 cap=3D8192 }, 48:{ span=3D48-55 cap=3D8192 }, 56:{ span=3D56-63 cap=3D8=
192 }, 64:{ span=3D64-71 cap=3D8192 }, 72:{ span=3D72-79 cap=3D8192 }, 80:{=
span=3D80-87 cap=3D8192 }, 88:{ span=3D88-95 cap=3D8192 }, 96:{ span=3D96-=
103 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8192 }, 112:{ span=3D112-119 c=
ap=3D8192 }, 120:{ span=3D120-127 cap=3D8192 }, 128:{ span=3D128-135 cap=3D=
8192 }, 136:{ span=3D136-143 cap=3D8192 }, 144:{ span=3D144-151 cap=3D8192 =
}, 152:{ span=3D152-159 cap=3D8192 }, 160:{ span=3D160-167 cap=3D8192 }, 16=
8:{ span=3D168-175 cap=3D8192 }, 176:{ span=3D176-183 cap=3D8192 }, 184:{ s=
pan=3D184-191 cap=3D8192 }, 192:{ span=3D192-199 cap=3D8192 }, 200:{ span=
=3D200-207 cap=3D8192 }, 208:{ span=3D208-215 cap=3D8192 }, 216:{ span=3D21=
6-223 cap=3D8192 }, 224:{ span=3D224-231 cap=3D8192 }, 232:{ span=3D232-239=
cap=3D8192 }, 240:{ span=3D240-247 cap=3D8192 }, 248:{ span=3D248-255 cap=
=3D8192 }, 256:{ span=3D256-263 cap=3D8192 }, 264:{ span=3D264-271 cap=3D81=
92 }, 272:{ span=3D272-279 cap=3D8192 }, 280:{ span=3D280-287 cap=3D8192 },=
288:{ span=3D288-295 cap=3D8192 }, 296:{ span=3D296-303 cap=3D8192 }, 0:{ =
span=3D0-7 cap=3D8192 }
After topology update.
For CPU 0
domain-0: span=3D0-7 level=3DSMT
groups: 0:{ span=3D0 }, 1:{ span=3D1 }, 2:{ span=3D2 }, 3:{ span=3D3 }, 4:=
{ span=3D4 }, 5:{ span=3D5 }, 6:{ span=3D6 }, 7:{ span=3D7 }
domain-1: span=3D0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,25=
6-263,288-295 level=3DDIE
groups: 0:{ span=3D0-7 cap=3D8192 }, 32:{ span=3D32-39 cap=3D8192 }, 64:{=
span=3D64-71 cap=3D8192 }, 96:{ span=3D96-103 cap=3D8192 }, 128:{ span=3D1=
28-135 cap=3D8192 }, 160:{ span=3D160-167 cap=3D8192 }, 192:{ span=3D192-19=
9 cap=3D8192 }, 224:{ span=3D224-231 cap=3D8192 }, 256:{ span=3D256-263 cap=
=3D8192 }, 288:{ span=3D288-295 cap=3D8192 }
domain-2: span=3D0-303 level=3DNODE
groups: 0:{ span=3D0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-23=
1,256-263,288-295 cap=3D81920 }, 8:{ span=3D8-15,40-47,72-79,104-111,136-14=
3,168-175,200-207,232-239,264-271,296-303 cap=3D81920 }, 16:{ span=3D16-23,=
48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=3D73728 }, =
24:{ span=3D24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-2=
87 cap=3D73728 }
For CPU 1
domain-0: span=3D0-7 level=3DSMT
groups: 1:{ span=3D1 }, 2:{ span=3D2 }, 3:{ span=3D3 }, 4:{ span=3D4 }, 5:=
{ span=3D5 }, 6:{ span=3D6 }, 7:{ span=3D7 }, 0:{ span=3D0 }
domain-1: span=3D0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,25=
6-263,288-295 level=3DDIE
groups: 0:{ span=3D0-7 cap=3D8192 }, 32:{ span=3D32-39 cap=3D8192 }, 64:{=
span=3D64-71 cap=3D8192 }, 96:{ span=3D96-103 cap=3D8192 }, 128:{ span=3D1=
28-135 cap=3D8192 }, 160:{ span=3D160-167 cap=3D8192 }, 192:{ span=3D192-19=
9 cap=3D8192 }, 224:{ span=3D224-231 cap=3D8192 }, 256:{ span=3D256-263 cap=
=3D8192 }, 288:{ span=3D288-295 cap=3D8192 }
domain-2: span=3D0-303 level=3DNODE
groups: 0:{ span=3D0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-23=
1,256-263,288-295 cap=3D81920 }, 8:{ span=3D8-15,40-47,72-79,104-111,136-14=
3,168-175,200-207,232-239,264-271,296-303 cap=3D81920 }, 16:{ span=3D16-23,=
48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=3D73728 }, =
24:{ span=3D24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-2=
87 cap=3D73728 }
For CPU 8
domain-0: span=3D8-15 level=3DSMT
groups: 8:{ span=3D8 }, 9:{ span=3D9 }, 10:{ span=3D10 }, 11:{ span=3D11 =
}, 12:{ span=3D12 }, 13:{ span=3D13 }, 14:{ span=3D14 }, 15:{ span=3D15 }
domain-1: span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239=
,264-271,296-303 level=3DDIE
groups: 8:{ span=3D8-15 cap=3D8192 }, 40:{ span=3D40-47 cap=3D8192 }, 72=
:{ span=3D72-79 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8192 }, 136:{ span=
=3D136-143 cap=3D8192 }, 168:{ span=3D168-175 cap=3D8192 }, 200:{ span=3D20=
0-207 cap=3D8192 }, 232:{ span=3D232-239 cap=3D8192 }, 264:{ span=3D264-271=
cap=3D8192 }, 296:{ span=3D296-303 cap=3D8192 }
domain-2: span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-23=
9,264-271,296-303 level=3DNODE
groups: 8:{ span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232=
-239,264-271,296-303 cap=3D81920 }
domain-3: span=3D0-303 level=3DNUMA
groups: 8:{ span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,23=
2-239,264-271,296-303 cap=3D81920 }, 16:{ span=3D16-23,48-55,80-87,112-119,=
144-151,176-183,208-215,240-247,272-279 cap=3D73728 }, 24:{ span=3D24-31,56=
-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=3D73728 }
ERROR: groups don't span domain->span
For CPU 9
domain-0: span=3D8-15 level=3DSMT
groups: 9:{ span=3D9 }, 10:{ span=3D10 }, 11:{ span=3D11 }, 12:{ span=3D1=
2 }, 13:{ span=3D13 }, 14:{ span=3D14 }, 15:{ span=3D15 }, 8:{ span=3D8 }
domain-1: span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239=
,264-271,296-303 level=3DDIE
groups: 8:{ span=3D8-15 cap=3D8192 }, 40:{ span=3D40-47 cap=3D8192 }, 72=
:{ span=3D72-79 cap=3D8192 }, 104:{ span=3D104-111 cap=3D8192 }, 136:{ span=
=3D136-143 cap=3D8192 }, 168:{ span=3D168-175 cap=3D8192 }, 200:{ span=3D20=
0-207 cap=3D8192 }, 232:{ span=3D232-239 cap=3D8192 }, 264:{ span=3D264-271=
cap=3D8192 }, 296:{ span=3D296-303 cap=3D8192 }
domain-2: span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-23=
9,264-271,296-303 level=3DNODE
groups: 8:{ span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,232=
-239,264-271,296-303 cap=3D81920 }
domain-3: span=3D0-303 level=3DNUMA
groups: 8:{ span=3D8-15,40-47,72-79,104-111,136-143,168-175,200-207,23=
2-239,264-271,296-303 cap=3D81920 }, 16:{ span=3D16-23,48-55,80-87,112-119,=
144-151,176-183,208-215,240-247,272-279 cap=3D73728 }, 24:{ span=3D24-31,56=
-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=3D73728 }
ERROR: groups don't span domain->span
--=20
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* [PATCH 2/2] powerpc/kexec: avoid hard coding when automatically allocating mem for crashkernel
From: Pingfan Liu @ 2018-08-31 7:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: Pingfan Liu, Benjamin Herrenschmidt, Michael Ellerman,
Hari Bathini, Mahesh Salgaonkar, Anton Blanchard
In-Reply-To: <1535700623-23750-1-git-send-email-kernelfans@gmail.com>
If no start address is specified for crashkernel, the current program hard
code as: crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
This limits the candidate memory region, and may cause failure while there
is enough mem for crashkernel. This patch suggests to find a suitable mem
chunk by memblock_find_in_range()
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Anton Blanchard <anton@samba.org>
---
arch/powerpc/kernel/machine_kexec.c | 24 +++++++++++++++---------
arch/powerpc/kernel/prom.c | 7 +++++--
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index 63f5a93..78005bf 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -22,6 +22,9 @@
#include <asm/pgalloc.h>
#include <asm/prom.h>
#include <asm/sections.h>
+#include <asm/mmu.h>
+
+#include "setup.h"
void machine_kexec_mask_interrupts(void) {
unsigned int i;
@@ -117,6 +120,7 @@ void machine_kexec(struct kimage *image)
void __init reserve_crashkernel(void)
{
unsigned long long crash_size, crash_base;
+ phys_addr_t start, up_boundary;
int ret;
/* use common parsing */
@@ -146,22 +150,24 @@ void __init reserve_crashkernel(void)
#else
if (!crashk_res.start) {
#ifdef CONFIG_PPC64
- /*
- * On 64bit we split the RMO in half but cap it at half of
- * a small SLB (128MB) since the crash kernel needs to place
- * itself and some stacks to be in the first segment.
- */
- crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
+ up_boundary = min(ppc64_bolted_size(), ppc64_rma_size);
+ start = memblock_find_in_range(KDUMP_KERNELBASE, up_boundary,
+ crash_size, PAGE_SIZE);
+ if (start == 0) {
+ pr_err("Failed to reserve memory for crashkernel!\n");
+ crashk_res.start = crashk_res.end = 0;
+ return;
+ } else
+ crashk_res.start = start;
#else
crashk_res.start = KDUMP_KERNELBASE;
#endif
}
- crash_base = PAGE_ALIGN(crashk_res.start);
- if (crash_base != crashk_res.start) {
+ if (crashk_res.start != PAGE_ALIGN(crashk_res.start)) {
printk("Crash kernel base must be aligned to 0x%lx\n",
PAGE_SIZE);
- crashk_res.start = crash_base;
+ crashk_res.start = PAGE_ALIGN(crashk_res.start);
}
#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index cae4a78..8b2ab99 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -688,6 +688,7 @@ static void tm_init(void) { }
void __init early_init_devtree(void *params)
{
phys_addr_t limit;
+ bool fadump_enabled = false;
DBG(" -> early_init_devtree(%p)\n", params);
@@ -737,9 +738,9 @@ void __init early_init_devtree(void *params)
* If we fail to reserve memory for firmware-assisted dump then
* fallback to kexec based kdump.
*/
- if (fadump_reserve_mem() == 0)
+ if (fadump_reserve_mem() == 1)
+ fadump_enabled = true;
#endif
- reserve_crashkernel();
early_reserve_mem();
/* Ensure that total memory size is page-aligned. */
@@ -761,6 +762,8 @@ void __init early_init_devtree(void *params)
dt_cpu_ftrs_scan();
mmu_early_init_devtree();
+ if (!fadump_enabled)
+ reserve_crashkernel();
/* Retrieve CPU related informations from the flat tree
* (altivec support, boot CPU ID, ...)
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox