All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "alex@ghiti.fr" <alex@ghiti.fr>,
	"will@kernel.org" <will@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Paul Mackerras <paulus@samba.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8)
Date: Fri, 11 Mar 2022 15:26:42 +1100	[thread overview]
Message-ID: <877d91m7wd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <ddfed61b-e387-4554-eb88-6654b391d1a4@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Hi Michael, hi Andrew
>
> Le 09/03/2022 à 18:44, Christophe Leroy a écrit :
>> Rebased on top of powerpc/next branch
>> 
>> This series converts powerpc to default topdown mmap layout.
>> 
>> powerpc requires its own arch_get_unmapped_area() only when
>> slices are needed, which is only for book3s/64. First part of
>> the series moves slices into book3s/64 specific directories
>> and cleans up other subarchitectures.
>> 
>> Last part converts to default topdown mmap layout.
>> 
>> A small modification is done to core mm to allow
>> powerpc to still provide its own arch_randomize_brk()
>> 
>> Another modification is done to core mm to allow powerpc
>> to use generic versions of get_unmapped_area functions for Radix
>> while still providing its own implementation for Hash, the
>> selection between Radix and Hash being doing at runtime.
>> 
>> Last modification to core mm is to give len and flags to
>> arch_get_mmap_end().
>> 
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> What's the way forward for this series ?

It's a bit of a tricky series.

> Patches 1 has been merged in PCI tree.

That's fine I guess, it can go into v5.18, it's only patch 14 that
depends on it.

> Patches 2 to 5 are core mm, patch 5 being a fix.

A fix for arm64 even, just to complicate things :)

> Then patches 6 to 14 are powerpc.

With a fairly sizable diffstat, ie. likely to conflict.

> What will be the merge strategy ? I guess it's a bit late to get it 
> through powerpc tree, so I was just wondering whether we could get 
> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ?

Yeah I didn't pick it up because the mm changes don't have many acks and
I'm always nervous about carrying generic mm changes.

It would be my preference if Andrew could take 2-5 through mm for v5.18,
but it is quite late, so I'm not sure how he will feel about that.

Arguably 2, 3, 4 do very little. It's only patch 5 that has much effect,
and it has a reviewed-by from Catalin at least.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8)
Date: Fri, 11 Mar 2022 15:26:42 +1100	[thread overview]
Message-ID: <877d91m7wd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <ddfed61b-e387-4554-eb88-6654b391d1a4@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Hi Michael, hi Andrew
>
> Le 09/03/2022 à 18:44, Christophe Leroy a écrit :
>> Rebased on top of powerpc/next branch
>> 
>> This series converts powerpc to default topdown mmap layout.
>> 
>> powerpc requires its own arch_get_unmapped_area() only when
>> slices are needed, which is only for book3s/64. First part of
>> the series moves slices into book3s/64 specific directories
>> and cleans up other subarchitectures.
>> 
>> Last part converts to default topdown mmap layout.
>> 
>> A small modification is done to core mm to allow
>> powerpc to still provide its own arch_randomize_brk()
>> 
>> Another modification is done to core mm to allow powerpc
>> to use generic versions of get_unmapped_area functions for Radix
>> while still providing its own implementation for Hash, the
>> selection between Radix and Hash being doing at runtime.
>> 
>> Last modification to core mm is to give len and flags to
>> arch_get_mmap_end().
>> 
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> What's the way forward for this series ?

It's a bit of a tricky series.

> Patches 1 has been merged in PCI tree.

That's fine I guess, it can go into v5.18, it's only patch 14 that
depends on it.

> Patches 2 to 5 are core mm, patch 5 being a fix.

A fix for arm64 even, just to complicate things :)

> Then patches 6 to 14 are powerpc.

With a fairly sizable diffstat, ie. likely to conflict.

> What will be the merge strategy ? I guess it's a bit late to get it 
> through powerpc tree, so I was just wondering whether we could get 
> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ?

Yeah I didn't pick it up because the mm changes don't have many acks and
I'm always nervous about carrying generic mm changes.

It would be my preference if Andrew could take 2-5 through mm for v5.18,
but it is quite late, so I'm not sure how he will feel about that.

Arguably 2, 3, 4 do very little. It's only patch 5 that has much effect,
and it has a reviewed-by from Catalin at least.

cheers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8)
Date: Fri, 11 Mar 2022 15:26:42 +1100	[thread overview]
Message-ID: <877d91m7wd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <ddfed61b-e387-4554-eb88-6654b391d1a4@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Hi Michael, hi Andrew
>
> Le 09/03/2022 à 18:44, Christophe Leroy a écrit :
>> Rebased on top of powerpc/next branch
>> 
>> This series converts powerpc to default topdown mmap layout.
>> 
>> powerpc requires its own arch_get_unmapped_area() only when
>> slices are needed, which is only for book3s/64. First part of
>> the series moves slices into book3s/64 specific directories
>> and cleans up other subarchitectures.
>> 
>> Last part converts to default topdown mmap layout.
>> 
>> A small modification is done to core mm to allow
>> powerpc to still provide its own arch_randomize_brk()
>> 
>> Another modification is done to core mm to allow powerpc
>> to use generic versions of get_unmapped_area functions for Radix
>> while still providing its own implementation for Hash, the
>> selection between Radix and Hash being doing at runtime.
>> 
>> Last modification to core mm is to give len and flags to
>> arch_get_mmap_end().
>> 
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> What's the way forward for this series ?

It's a bit of a tricky series.

> Patches 1 has been merged in PCI tree.

That's fine I guess, it can go into v5.18, it's only patch 14 that
depends on it.

> Patches 2 to 5 are core mm, patch 5 being a fix.

A fix for arm64 even, just to complicate things :)

> Then patches 6 to 14 are powerpc.

With a fairly sizable diffstat, ie. likely to conflict.

> What will be the merge strategy ? I guess it's a bit late to get it 
> through powerpc tree, so I was just wondering whether we could get 
> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ?

Yeah I didn't pick it up because the mm changes don't have many acks and
I'm always nervous about carrying generic mm changes.

It would be my preference if Andrew could take 2-5 through mm for v5.18,
but it is quite late, so I'm not sure how he will feel about that.

Arguably 2, 3, 4 do very little. It's only patch 5 that has much effect,
and it has a reviewed-by from Catalin at least.

cheers


  reply	other threads:[~2022-03-11  4:27 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 17:44 [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8) Christophe Leroy
2022-03-09 17:44 ` Christophe Leroy
2022-03-09 17:44 ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 01/14] sizes.h: Add SZ_1T macro Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-10 16:52   ` Bjorn Helgaas
2022-03-10 16:52     ` Bjorn Helgaas
2022-03-10 16:52     ` Bjorn Helgaas
2022-03-10 18:09     ` Christophe Leroy
2022-03-10 18:09       ` Christophe Leroy
2022-03-10 18:09       ` Christophe Leroy
2022-03-10 18:21       ` Bjorn Helgaas
2022-03-10 18:21         ` Bjorn Helgaas
2022-03-10 18:21         ` Bjorn Helgaas
2022-03-09 17:44 ` [PATCH v8 02/14] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 03/14] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 04/14] mm: Add len and flags parameters to arch_get_mmap_end() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 05/14] mm, hugetlbfs: Allow for "high" userspace addresses Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 06/14] powerpc/mm: Move vma_mmu_pagesize() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 07/14] powerpc/mm: Make slice specific to book3s/64 Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 08/14] powerpc/mm: Remove CONFIG_PPC_MM_SLICES Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 09/14] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 10/14] powerpc/mm: Use generic_hugetlb_get_unmapped_area() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 11/14] powerpc/mm: Move get_unmapped_area functions to slice.c Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 12/14] powerpc/mm: Enable full randomisation of memory mappings Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 13/14] powerpc/mm: Convert to default topdown mmap layout Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 14/14] powerpc: Simplify and move arch_randomize_brk() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-10  6:51 ` [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8) Christophe Leroy
2022-03-10  6:51   ` Christophe Leroy
2022-03-10  6:51   ` Christophe Leroy
2022-03-11  4:26   ` Michael Ellerman [this message]
2022-03-11  4:26     ` Michael Ellerman
2022-03-11  4:26     ` Michael Ellerman
2022-03-11  4:49     ` Andrew Morton
2022-03-11  4:49       ` Andrew Morton
2022-03-11  4:49       ` Andrew Morton
2022-04-04  5:22       ` Christophe Leroy
2022-04-04  5:22         ` Christophe Leroy
2022-04-04  5:22         ` Christophe Leroy
2022-04-07 18:30         ` Christophe Leroy
2022-04-07 18:30           ` Christophe Leroy
2022-04-07 18:30           ` Christophe Leroy
2022-04-08  4:18           ` Michael Ellerman
2022-04-08  4:18             ` Michael Ellerman
2022-04-08  4:18             ` Michael Ellerman
2022-04-08  4:17       ` Michael Ellerman
2022-04-08  4:17         ` Michael Ellerman
2022-04-08  4:17         ` Michael Ellerman

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=877d91m7wd.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.