Re: [PATCH] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread Christophe Leroy
Le 02/05/2021 à 06:56, Nicholas Piggin a écrit : This reduces TLB misses by nearly 30x on a `git diff` workload on a 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due to vfs hashes being allocated with 2MB pages. Acked-by: Michael Ellerman Signed-off-by: Nicholas Piggin -

Re: [PATCH] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread kernel test robot
, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-radix-Enable-huge-vmalloc-mappings/20210502-125808 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linu

Re: [PATCH] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread kernel test robot
use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-radix-Enable-huge-vmalloc-mappings/20210502-125808 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next confi

Re: [PATCH] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread Nicholas Piggin
Excerpts from Christophe Leroy's message of May 2, 2021 5:34 pm: > > > Le 02/05/2021 à 06:56, Nicholas Piggin a écrit : >> This reduces TLB misses by nearly 30x on a `git diff` workload on a >> 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due >> to vfs hashes being allocated w

[PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread Nicholas Piggin
This reduces TLB misses by nearly 30x on a `git diff` workload on a 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due to vfs hashes being allocated with 2MB pages. Acked-by: Michael Ellerman Signed-off-by: Nicholas Piggin --- Since v1: - Don't define MODULES_VADDR which has so

Re: [PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread kernel test robot
suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-radix-Enable-huge-vmalloc-mappings/20210502-190249 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git n

Re: [PATCH 1/4] powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks

2021-05-02 Thread Michael Ellerman
Nicholas Piggin writes: > Excerpts from Naveen N. Rao's message of April 27, 2021 11:43 pm: >> Nicholas Piggin wrote: >>> The paravit queued spinlock slow path adds itself to the queue then >>> calls pv_wait to wait for the lock to become free. This is implemented >>> by calling H_CONFER to donate

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-02 Thread Michal Suchánek
On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote: > Provide an option to use ELFv2 ABI for big endian builds. This works on > GCC and clang (since 2014). It is less well tested and supported by the > GNU toolchain, but it can give some useful advantages of the ELFv2 ABI > for BE (e.g

Re: [PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread Christophe Leroy
Le 02/05/2021 à 13:00, Nicholas Piggin a écrit : This reduces TLB misses by nearly 30x on a `git diff` workload on a 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due to vfs hashes being allocated with 2MB pages. Acked-by: Michael Ellerman Signed-off-by: Nicholas Piggin -

[PATCH] powerpc: Don't opencode HAVE_EFFICIENT_UNALIGNED_ACCESS

2021-05-02 Thread Michal Suchanek
There is some disconnect between commit 8a18cc0c2c36 ("powerpc: Only disable HAVE_EFFICIENT_UNALIGNED_ACCESS on POWER7 little endian") and commit a75c380c7129 ("powerpc: Enable DCACHE_WORD_ACCESS on ppc64le"). The first defines HAVE_EFFICIENT_UNALIGNED_ACCESS for the purpose of enabling DCACHE_WOR

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-02 Thread Segher Boessenkool
On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote: > Excerpts from Segher Boessenkool's message of April 29, 2020 9:40 am: > I blame toolchain for -mabi=elfv2 ! And also some blame on ABI document > which is called ELF V2 ABI rather than ELF ABI V2 which would have been > unambiguou

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Segher Boessenkool
On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote: > Why not raise the minimum gcc compiler version even higher? The latest GCC 5 release is only three and a half years old. Do you really want to require bleeding edge tools? Segher

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Segher Boessenkool
On Sun, May 02, 2021 at 12:15:38AM +0900, Masahiro Yamada wrote: > The current minimum GCC version is 4.9 except ARCH=arm64 requiring > GCC 5.1. > > When we discussed last time, we agreed to raise the minimum GCC version > to 5.1 globally. [1] > > I'd like to propose GCC 5.2 to clean up arch/powe

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Joe Perches
On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote: > On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote: > > Why not raise the minimum gcc compiler version even higher? On Sun, 2021-05-02 at 13:37 -0500, Segher Boessenkool wrote: > Everyone should always use an as new release as

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Segher Boessenkool
On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote: > On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote: > > On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote: > > > Why not raise the minimum gcc compiler version even higher? > > On Sun, 2021-05-02 at 13:37 -0500, Segh

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Linus Torvalds
On Sun, May 2, 2021 at 1:38 PM Segher Boessenkool wrote: > > The point is, you inconvenience users if you require a compiler version > they do not already have. Five years might be fine, but three years is > not. So this should be our main issue - not how old a compiler is, but how our compiler

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Joe Perches
On Sun, 2021-05-02 at 15:32 -0500, Segher Boessenkool wrote: > On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote: [] > > Perhaps 8 might be best as that has a __diag warning control mechanism. > > I have no idea what you mean? ? read the last bit of compiler-gcc.h

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Ali Kaasinen
On 02/05/2021 23.32, Segher Boessenkool wrote: On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote: On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote: On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote: Why not raise the minimum gcc compiler version even higher? On

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Matthew Wilcox
On Sun, May 02, 2021 at 02:08:31PM -0700, Linus Torvalds wrote: > What is relevant is what version of gcc various distributions actually > have reasonably easily available, and how old and relevant the > distributions are. We did decide that (just as an example) RHEL 7 was > too old to worry about

Re: [PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings

2021-05-02 Thread Nicholas Piggin
Excerpts from Christophe Leroy's message of May 3, 2021 3:11 am: > > > Le 02/05/2021 à 13:00, Nicholas Piggin a écrit : >> This reduces TLB misses by nearly 30x on a `git diff` workload on a >> 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due >> to vfs hashes being allocated w

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-02 Thread Nicholas Piggin
Excerpts from Segher Boessenkool's message of May 3, 2021 3:55 am: > On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote: >> Excerpts from Segher Boessenkool's message of April 29, 2020 9:40 am: >> I blame toolchain for -mabi=elfv2 ! And also some blame on ABI document >> which is call

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Segher Boessenkool
On Sun, May 02, 2021 at 02:23:01PM -0700, Joe Perches wrote: > On Sun, 2021-05-02 at 15:32 -0500, Segher Boessenkool wrote: > > On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote: > [] > > > Perhaps 8 might be best as that has a __diag warning control mechanism. > > > > I have no idea wha

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-02 Thread Nicholas Piggin
Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am: > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote: >> Provide an option to use ELFv2 ABI for big endian builds. This works on >> GCC and clang (since 2014). It is less well tested and supported by the >> GNU toolchain,

Re: [PATCH v11 1/9] powerpc/mm: Implement set_memory() routines

2021-05-02 Thread Jordan Niethe
On Thu, Apr 29, 2021 at 5:32 PM Christophe Leroy wrote: > > > > Le 29/04/2021 à 05:15, Jordan Niethe a écrit : > > From: Russell Currey > > > > The set_memory_{ro/rw/nx/x}() functions are required for > > STRICT_MODULE_RWX, and are generally useful primitives to have. This > > implementation is

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Jordan Niethe
On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy wrote: > > > > Le 29/04/2021 à 05:15, Jordan Niethe a écrit : > > If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and > > VMALLOC_END respectively. This reduces the need for special cases. For > > example, powerpc's module_alloc() w

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Christophe Leroy
Le 03/05/2021 à 07:39, Jordan Niethe a écrit : On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy wrote: Le 29/04/2021 à 05:15, Jordan Niethe a écrit : If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and VMALLOC_END respectively. This reduces the need for special cases. Fo

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Jordan Niethe
On Mon, May 3, 2021 at 3:57 PM Christophe Leroy wrote: > > > > Le 03/05/2021 à 07:39, Jordan Niethe a écrit : > > On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy > > wrote: > >> > >> > >> > >> Le 29/04/2021 à 05:15, Jordan Niethe a écrit : > >>> If MODULES_{VADDR,END} are not defined set them to

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-02 Thread Christophe Leroy
Le 01/05/2021 à 17:15, Masahiro Yamada a écrit : The current minimum GCC version is 4.9 except ARCH=arm64 requiring GCC 5.1. When we discussed last time, we agreed to raise the minimum GCC version to 5.1 globally. [1] I'd like to propose GCC 5.2 to clean up arch/powerpc/Kconfig as well. On

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Christophe Leroy
Le 03/05/2021 à 08:16, Jordan Niethe a écrit : On Mon, May 3, 2021 at 3:57 PM Christophe Leroy wrote: Le 03/05/2021 à 07:39, Jordan Niethe a écrit : On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy wrote: Le 29/04/2021 à 05:15, Jordan Niethe a écrit : If MODULES_{VADDR,END} are not

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Jordan Niethe
On Mon, May 3, 2021 at 4:22 PM Christophe Leroy wrote: > > > > Le 03/05/2021 à 08:16, Jordan Niethe a écrit : > > On Mon, May 3, 2021 at 3:57 PM Christophe Leroy > > wrote: > >> > >> > >> > >> Le 03/05/2021 à 07:39, Jordan Niethe a écrit : > >>> On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy >

Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}

2021-05-02 Thread Christophe Leroy
Le 03/05/2021 à 08:26, Jordan Niethe a écrit : On Mon, May 3, 2021 at 4:22 PM Christophe Leroy wrote: Le 03/05/2021 à 08:16, Jordan Niethe a écrit : On Mon, May 3, 2021 at 3:57 PM Christophe Leroy wrote: Le 03/05/2021 à 07:39, Jordan Niethe a écrit : On Thu, Apr 29, 2021 at 3:04 PM