From: Mike Rapoport <rppt@linux.ibm.com> To: Adam Ford <aford173@gmail.com> Cc: Fabio Estevam <festevam@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de>, Russell King <linux@armlinux.org.uk>, The etnaviv authors <etnaviv@lists.freedesktop.org>, arm-soc <linux-arm-kernel@lists.infradead.org>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Lucas Stach <l.stach@pengutronix.de> Subject: Re: [PATCH v2 00/21] Refine memblock API Date: Thu, 3 Oct 2019 08:34:52 +0300 [thread overview] Message-ID: <20191003053451.GA23397@linux.ibm.com> (raw) In-Reply-To: <CAHCN7xL1MkJh44N3W_1+08DHmX__SqnfH6dqUzYzr2Wpg0kQyQ@mail.gmail.com> (trimmed the CC) On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Before the patch: > > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 34: 0x2fffff88..0x3fffffff > > > After the patch: > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 36: 0x80000000..0x8fffffff I'm still not convinced that the memblock refactoring didn't uncovered an issue in etnaviv driver. Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? BTW, the code that complained about "command buffer outside valid memory window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2"). Could be that recent changes to MMU management of etnaviv resolve the issue? > > From 06529f861772b7dea2912fc2245debe4690139b8 Mon Sep 17 00:00:00 2001 > > From: Mike Rapoport <rppt@linux.ibm.com> > > Date: Wed, 2 Oct 2019 10:14:17 +0300 > > Subject: [PATCH] mm: memblock: do not enforce current limit for memblock_phys* > > family > > > > Until commit 92d12f9544b7 ("memblock: refactor internal allocation > > functions") the maximal address for memblock allocations was forced to > > memblock.current_limit only for the allocation functions returning virtual > > address. The changes introduced by that commit moved the limit enforcement > > into the allocation core and as a result the allocation functions returning > > physical address also started to limit allocations to > > memblock.current_limit. > > > > This caused breakage of etnaviv GPU driver: > > > > [ 3.682347] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) > > [ 3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) > > [ 3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) > > [ 3.700800] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 > > [ 3.723013] etnaviv-gpu 130000.gpu: command buffer outside valid > > memory window > > [ 3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > > [ 3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid > > memory window > > [ 3.760583] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > > [ 3.766766] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > > > > Restore the behaviour of memblock_phys* family so that these functions will > > not enforce memblock.current_limit. > > > > This fixed the issue. Thank you > > Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd > > > Fixes: 92d12f9544b7 ("memblock: refactor internal allocation functions") > > Reported-by: Adam Ford <aford173@gmail.com> > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > > --- > > mm/memblock.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 7d4f61a..c4b16ca 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > align = SMP_CACHE_BYTES; > > } > > > > - if (end > memblock.current_limit) > > - end = memblock.current_limit; > > - > > again: > > found = memblock_find_in_range_node(size, align, start, end, nid, > > flags); > > @@ -1469,6 +1466,9 @@ static void * __init memblock_alloc_internal( > > if (WARN_ON_ONCE(slab_is_available())) > > return kzalloc_node(size, GFP_NOWAIT, nid); > > > > + if (max_addr > memblock.current_limit) > > + max_addr = memblock.current_limit; > > + > > alloc = memblock_alloc_range_nid(size, align, min_addr, max_addr, nid); > > > > /* retry allocation without lower limit */ > > -- > > 2.7.4 > > > > > > > > adam > > > > > > > > On Sat, Sep 28, 2019 at 2:33 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > On Thu, Sep 26, 2019 at 02:35:53PM -0500, Adam Ford wrote: > > > > > > On Thu, Sep 26, 2019 at 11:04 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > > > > > > > > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam <festevam@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford <aford173@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > > > > > > > > change. Do we need to setup a reserved-memory node like > > > > > > > > > > imx6ul-ccimx6ulsom.dtsi did? > > > > > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > > > > > Were you able to identify what was the exact commit that caused such regression? > > > > > > > > > > > > > > > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > > > > > > > > internal allocation functions") that caused the regression with > > > > > > > > Etnaviv. > > > > > > > > > > > > > > > > > > > > > Can you please test with this change: > > > > > > > > > > > > > > > > > > > That appears to have fixed my issue. I am not sure what the impact > > > > > > is, but is this a safe option? > > > > > > > > > > It's not really a fix, I just wanted to see how exactly 92d12f9544b7 ("memblock: > > > > > refactor internal allocation functions") broke your setup. > > > > > > > > > > Can you share the dts you are using and the full kernel log? > > > > > > > > > > > adam > > > > > > > > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > > > > > index 7d4f61a..1f5a0eb 100644 > > > > > > > --- a/mm/memblock.c > > > > > > > +++ b/mm/memblock.c > > > > > > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > > > > > > align = SMP_CACHE_BYTES; > > > > > > > } > > > > > > > > > > > > > > - if (end > memblock.current_limit) > > > > > > > - end = memblock.current_limit; > > > > > > > - > > > > > > > again: > > > > > > > found = memblock_find_in_range_node(size, align, start, end, nid, > > > > > > > flags); > > > > > > > > > > > > > > > I also noticed that if I create a reserved memory node as was done one > > > > > > > > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > > > > > > > > was getting errors regardless of the 'cma=256M' or not. > > > > > > > > I don't have a problem using the reserved memory, but I guess I am not > > > > > > > > sure what the amount should be. I know for the video decoding 1080p, > > > > > > > > I have historically used cma=128M, but with the 3D also needing some > > > > > > > > memory allocation, is that enough or should I use 256M? > > > > > > > > > > > > > > > > adam > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > Mike. > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > Mike. > > > > > > > > > -- > > Sincerely yours, > > Mike. > > -- Sincerely yours, Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com> To: Adam Ford <aford173@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com>, Russell King <linux@armlinux.org.uk>, The etnaviv authors <etnaviv@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Fabio Estevam <festevam@gmail.com>, Christoph Hellwig <hch@lst.de>, arm-soc <linux-arm-kernel@lists.infradead.org>, Lucas Stach <l.stach@pengutronix.de> Subject: Re: [PATCH v2 00/21] Refine memblock API Date: Thu, 3 Oct 2019 08:34:52 +0300 [thread overview] Message-ID: <20191003053451.GA23397@linux.ibm.com> (raw) In-Reply-To: <CAHCN7xL1MkJh44N3W_1+08DHmX__SqnfH6dqUzYzr2Wpg0kQyQ@mail.gmail.com> (trimmed the CC) On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Before the patch: > > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 34: 0x2fffff88..0x3fffffff > > > After the patch: > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 36: 0x80000000..0x8fffffff I'm still not convinced that the memblock refactoring didn't uncovered an issue in etnaviv driver. Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? BTW, the code that complained about "command buffer outside valid memory window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2"). Could be that recent changes to MMU management of etnaviv resolve the issue? > > From 06529f861772b7dea2912fc2245debe4690139b8 Mon Sep 17 00:00:00 2001 > > From: Mike Rapoport <rppt@linux.ibm.com> > > Date: Wed, 2 Oct 2019 10:14:17 +0300 > > Subject: [PATCH] mm: memblock: do not enforce current limit for memblock_phys* > > family > > > > Until commit 92d12f9544b7 ("memblock: refactor internal allocation > > functions") the maximal address for memblock allocations was forced to > > memblock.current_limit only for the allocation functions returning virtual > > address. The changes introduced by that commit moved the limit enforcement > > into the allocation core and as a result the allocation functions returning > > physical address also started to limit allocations to > > memblock.current_limit. > > > > This caused breakage of etnaviv GPU driver: > > > > [ 3.682347] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) > > [ 3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) > > [ 3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) > > [ 3.700800] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 > > [ 3.723013] etnaviv-gpu 130000.gpu: command buffer outside valid > > memory window > > [ 3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > > [ 3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid > > memory window > > [ 3.760583] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > > [ 3.766766] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > > > > Restore the behaviour of memblock_phys* family so that these functions will > > not enforce memblock.current_limit. > > > > This fixed the issue. Thank you > > Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd > > > Fixes: 92d12f9544b7 ("memblock: refactor internal allocation functions") > > Reported-by: Adam Ford <aford173@gmail.com> > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > > --- > > mm/memblock.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 7d4f61a..c4b16ca 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > align = SMP_CACHE_BYTES; > > } > > > > - if (end > memblock.current_limit) > > - end = memblock.current_limit; > > - > > again: > > found = memblock_find_in_range_node(size, align, start, end, nid, > > flags); > > @@ -1469,6 +1466,9 @@ static void * __init memblock_alloc_internal( > > if (WARN_ON_ONCE(slab_is_available())) > > return kzalloc_node(size, GFP_NOWAIT, nid); > > > > + if (max_addr > memblock.current_limit) > > + max_addr = memblock.current_limit; > > + > > alloc = memblock_alloc_range_nid(size, align, min_addr, max_addr, nid); > > > > /* retry allocation without lower limit */ > > -- > > 2.7.4 > > > > > > > > adam > > > > > > > > On Sat, Sep 28, 2019 at 2:33 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > On Thu, Sep 26, 2019 at 02:35:53PM -0500, Adam Ford wrote: > > > > > > On Thu, Sep 26, 2019 at 11:04 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > > > > > > > > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam <festevam@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford <aford173@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > > > > > > > > change. Do we need to setup a reserved-memory node like > > > > > > > > > > imx6ul-ccimx6ulsom.dtsi did? > > > > > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > > > > > Were you able to identify what was the exact commit that caused such regression? > > > > > > > > > > > > > > > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > > > > > > > > internal allocation functions") that caused the regression with > > > > > > > > Etnaviv. > > > > > > > > > > > > > > > > > > > > > Can you please test with this change: > > > > > > > > > > > > > > > > > > > That appears to have fixed my issue. I am not sure what the impact > > > > > > is, but is this a safe option? > > > > > > > > > > It's not really a fix, I just wanted to see how exactly 92d12f9544b7 ("memblock: > > > > > refactor internal allocation functions") broke your setup. > > > > > > > > > > Can you share the dts you are using and the full kernel log? > > > > > > > > > > > adam > > > > > > > > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > > > > > index 7d4f61a..1f5a0eb 100644 > > > > > > > --- a/mm/memblock.c > > > > > > > +++ b/mm/memblock.c > > > > > > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > > > > > > align = SMP_CACHE_BYTES; > > > > > > > } > > > > > > > > > > > > > > - if (end > memblock.current_limit) > > > > > > > - end = memblock.current_limit; > > > > > > > - > > > > > > > again: > > > > > > > found = memblock_find_in_range_node(size, align, start, end, nid, > > > > > > > flags); > > > > > > > > > > > > > > > I also noticed that if I create a reserved memory node as was done one > > > > > > > > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > > > > > > > > was getting errors regardless of the 'cma=256M' or not. > > > > > > > > I don't have a problem using the reserved memory, but I guess I am not > > > > > > > > sure what the amount should be. I know for the video decoding 1080p, > > > > > > > > I have historically used cma=128M, but with the 3D also needing some > > > > > > > > memory allocation, is that enough or should I use 256M? > > > > > > > > > > > > > > > > adam > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > Mike. > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > Mike. > > > > > > > > > -- > > Sincerely yours, > > Mike. > > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-03 5:35 UTC|newest] Thread overview: 470+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-21 8:03 [PATCH v2 00/21] Refine memblock API Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] openrisc: prefer memblock APIs returning virtual address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,01/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [OpenRISC] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [v2,01/21] " Stafford Horne 2019-01-27 3:07 ` [PATCH v2 01/21] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-21 8:03 ` [PATCH v2 02/21] powerpc: use memblock functions " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,02/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 02/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [v2,02/21] " Michael Ellerman 2019-01-29 9:52 ` [PATCH v2 02/21] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,03/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] memblock: drop memblock_alloc_base_nid() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,04/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,05/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,06/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [OpenRISC] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [v2,06/21] " Catalin Marinas 2019-01-25 17:45 ` [PATCH v2 06/21] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [OpenRISC] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [v2,06/21] " Mike Rapoport 2019-01-25 19:32 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:56 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:58 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] memblock: memblock_phys_alloc(): " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,07/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] memblock: drop __memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,08/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] memblock: drop memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,09/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [OpenRISC] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [v2,09/21] " Michael Ellerman 2019-01-29 10:29 ` [PATCH v2 09/21] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-21 8:03 ` [PATCH v2 10/21] memblock: refactor internal allocation functions Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,10/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 10/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [OpenRISC] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [v2,10/21] " Michael Ellerman 2019-02-03 9:39 ` [PATCH v2 10/21] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [OpenRISC] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [v2,10/21] " Mike Rapoport 2019-02-03 10:04 ` [PATCH v2 10/21] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-04 8:45 ` Michael Ellerman 2019-02-04 8:45 ` Michael Ellerman 2019-02-04 23:08 ` Stephen Rothwell 2019-02-04 23:08 ` Stephen Rothwell 2019-01-21 8:03 ` [PATCH v2 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,11/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 11/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,12/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] arch: don't memset(0) memory returned by memblock_alloc() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,13/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] ia64: add checks for the return value of memblock_alloc*() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,14/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] sparc: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,15/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] mm/percpu: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,16/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] init/main: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,17/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] swiotlb: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,18/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] treewide: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,19/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` [OpenRISC] " Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [OpenRISC] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [v2,19/21] " Rob Herring 2019-01-21 17:18 ` [PATCH v2 19/21] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [OpenRISC] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [v2,19/21] " Mike Rapoport 2019-01-31 6:41 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:44 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 7:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [OpenRISC] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [v2,19/21] " Mike Rapoport 2019-01-31 7:14 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` [OpenRISC] " Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] memblock: memblock_alloc_try_nid: don't panic Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,20/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,21/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [OpenRISC] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [v2,21/21] " Petr Mladek 2019-01-30 13:38 ` [PATCH v2 21/21] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-09-24 17:52 ` [PATCH v2 00/21] Refine memblock API Adam Ford 2019-09-24 17:52 ` [OpenRISC] " Adam Ford 2019-09-24 17:52 ` [Xen-devel] " Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` [OpenRISC] " Fabio Estevam 2019-09-25 12:12 ` [Xen-devel] " Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` [OpenRISC] " Adam Ford 2019-09-25 12:17 ` [Xen-devel] " Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` [OpenRISC] " Fabio Estevam 2019-09-25 15:17 ` [Xen-devel] " Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` [OpenRISC] " Adam Ford 2019-09-26 13:09 ` [Xen-devel] " Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` [OpenRISC] " Mike Rapoport 2019-09-26 16:04 ` [Xen-devel] " Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` [OpenRISC] " Adam Ford 2019-09-26 19:35 ` [Xen-devel] " Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` [OpenRISC] " Mike Rapoport 2019-09-28 7:33 ` [Xen-devel] " Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` [OpenRISC] " Adam Ford 2019-09-29 13:33 ` [Xen-devel] " Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` [OpenRISC] " Adam Ford 2019-10-02 0:14 ` [Xen-devel] " Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` [OpenRISC] " Mike Rapoport 2019-10-02 7:36 ` [Xen-devel] " Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` [OpenRISC] " Adam Ford 2019-10-02 11:14 ` [Xen-devel] " Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-03 5:34 ` Mike Rapoport [this message] 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-01-21 8:03 Mike Rapoport
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=20191003053451.GA23397@linux.ibm.com \ --to=rppt@linux.ibm.com \ --cc=aford173@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=etnaviv@lists.freedesktop.org \ --cc=festevam@gmail.com \ --cc=hch@lst.de \ --cc=l.stach@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ /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: linkBe 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.