Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-22 Thread Alex Ghiti
Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit : On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote: On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: > > I guess I don't understand why this is necessary at all. > > Specifically: why > > can'

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-22 Thread Alex Ghiti
sets have imposed a significant performance penalty on all systems). Alex Alex Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit : Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocata

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-22 Thread Alex Ghiti
Hi Benjamin, Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit : On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: I guess I don't understand why this is necessary at all. Specifically: why can't we just relocate the kernel within the linear map? That would let the bootloader put

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-21 Thread Alex Ghiti
Let's try to make progress here: I add linux-mm in CC to get feedback on this patch as it blocks sv48 support too. Alex Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit : Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-09 Thread Alex Ghiti
Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory.

Re: [PATCH v5 0/4] vmalloc kernel mapping and relocatable kernel

2020-07-07 Thread Alex Ghiti
Hi Palmer, Le 6/7/20 à 3:59 AM, Alexandre Ghiti a écrit : This patchset originally implemented relocatable kernel support but now also moves the kernel mapping into the vmalloc zone. The first patch explains why

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-06-12 Thread Alex Ghiti
Hi Atish, Le 6/11/20 à 5:34 PM, Atish Patra a écrit : On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore,

Re: [PATCH v5 2/4] riscv: Introduce CONFIG_RELOCATABLE

2020-06-11 Thread Alex Ghiti
Hi Jerome, Le 6/10/20 à 10:10 AM, Jerome Forissier a écrit : On 6/7/20 9:59 AM, Alexandre Ghiti wrote: [...] +config RELOCATABLE + bool + depends on MMU + help + This builds a kernel as a Position Independent Executable (PIE), + which retains all relocation

Re: [PATCH v4 1/4] riscv: Move kernel mapping to vmalloc zone

2020-06-05 Thread Alex Ghiti
Hi Zong, Le 6/3/20 à 10:52 PM, Zong Li a écrit : On Wed, Jun 3, 2020 at 4:01 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore, we

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

2020-05-28 Thread Alex Ghiti
Hi Zong, Le 5/27/20 à 3:29 AM, Alex Ghiti a écrit : Le 5/27/20 à 2:05 AM, Zong Li a écrit : On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote: Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

2020-05-27 Thread Alex Ghiti
Le 5/27/20 à 2:05 AM, Zong Li a écrit : On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote: Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

2020-05-26 Thread Alex Ghiti
Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore, we

Re: [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad

2020-01-30 Thread Alex Ghiti
On 1/18/20 12:03 PM, Alexandre Ghiti wrote: Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak symbols that may be unresolved at link time which result in an absolute relocation to 0. relocs_check.sh emits the following warning: "WARNING: 2 bad relocations c1a41478

Re: [PATCH] powerpc: Do not consider weak unresolved symbol relocations as bad

2020-01-16 Thread Alex Ghiti
Hi Stephen, On 1/15/20 6:39 PM, Stephen Rothwell wrote: Hi Alexandre, Thanks for sorting this out. Just a few comments below. On Wed, 15 Jan 2020 15:46:48 -0500 Alexandre Ghiti wrote: # Have Kbuild supply the path to objdump so we handle cross compilation.

Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-29 Thread Alex Ghiti
On 3/28/19 4:43 PM, Mike Kravetz wrote: On 3/26/19 11:36 PM, Alexandre Ghiti wrote: On systems without CONTIG_ALLOC activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patch simply enables the possibility to hand back those pages to memory

Re: [PATCH v7 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-18 Thread Alex Ghiti
On 3/17/19 2:31 PM, christophe leroy wrote: Le 17/03/2019 à 17:28, Alexandre Ghiti a écrit : On systems without CONTIG_ALLOC activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patch simply enables the possibility to hand back those pages

Re: [PATCH v6 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-09 Thread Alex Ghiti
On 3/8/19 2:05 PM, Mike Kravetz wrote: On 3/7/19 5:20 AM, Alexandre Ghiti wrote: On systems without CONTIG_ALLOC activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patch simply enables the possibility to hand back those pages to memory

Re: [PATCH v5 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-06 Thread Alex Ghiti
On 3/6/19 2:16 PM, Dave Hansen wrote: On 3/6/19 11:00 AM, Alexandre Ghiti wrote: +static int set_max_huge_pages(struct hstate *h, unsigned long count, + nodemask_t *nodes_allowed) { unsigned long min_count, ret; - if (hstate_is_gigantic(h) &&

Re: [PATCH v5 3/4] mm: Simplify MEMORY_ISOLATION && COMPACTION || CMA into CONTIG_ALLOC

2019-03-06 Thread Alex Ghiti
On 3/6/19 2:30 PM, Vlastimil Babka wrote: On 3/6/19 8:00 PM, Alexandre Ghiti wrote: This condition allows to define alloc_contig_range, so simplify it into a more accurate naming. Suggested-by: Vlastimil Babka Signed-off-by: Alexandre Ghiti Acked-by: Vlastimil Babka (you could have sent

Re: [PATCH v5 2/4] sparc: Advertise gigantic page support

2019-03-06 Thread Alex Ghiti
On 3/6/19 2:04 PM, David Miller wrote: From: Alexandre Ghiti Date: Wed, 6 Mar 2019 14:00:03 -0500 sparc actually supports gigantic pages and selecting ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free gigantic pages at runtime. sparc allows configuration such as huge pages of 16GB,

Re: [PATCH v3] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-17 Thread Alex Ghiti
On 2/15/19 12:34 PM, Dave Hansen wrote: -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA) +#ifdef CONFIG_CONTIG_ALLOC /* The below functions must be run on a range from a single zone. */ extern int alloc_contig_range(unsigned long start, unsigned

Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-13 Thread Alex Ghiti
On 2/13/19 6:27 AM, Vlastimil Babka wrote: On 1/17/19 7:39 PM, Alexandre Ghiti wrote: From: Alexandre Ghiti On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply

Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-05 Thread Alex Ghiti
On 2/5/19 6:23 AM, Michael Ellerman wrote: Alexandre Ghiti writes: From: Alexandre Ghiti On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply enables the possibility

Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-03 Thread Alex Ghiti
On 1/17/19 1:39 PM, Alexandre Ghiti wrote: From: Alexandre Ghiti On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply enables the possibility to hand back those pages

Re: [PATCH v6 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-08-13 Thread Alex Ghiti
Hi everyone, Does someone need anything more to be done regarding this series ? Thanks, Alex On 08/06/2018 05:57 PM, Alexandre Ghiti wrote: [CC linux-mm for inclusion in -mm tree] In order to reduce

Re: [PATCH v6 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-08-07 Thread Alex Ghiti
Thanks for your time, Alex Le 07/08/2018 à 09:54, Ingo Molnar a écrit : * Alexandre Ghiti wrote: [CC linux-mm for inclusion in -mm tree] In order to reduce copy/paste of functions across architectures and

Re: [PATCH v5 09/11] hugetlb: Introduce generic version of huge_ptep_set_wrprotect

2018-08-02 Thread Alex Ghiti
Ok, I tried every defconfig available: - for the nohash/32, I found that I could use mpc885_ads_defconfig and I activated HUGETLBFS. I removed the definition of huge_ptep_set_wrprotect from nohash/32/pgtable.h, add an #error in include/asm-generic/hugetlb.h right before the generic definition

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-26 Thread Alex Ghiti
://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ On 07/26/2018 05:01 PM, Alex Ghiti wrote: Hi Helge, Thanks for your tests. In case it can help you, this is what I get when I try to build generic-64bit_defconfig (I truncated the output): ...  LD  vmlinux.o  MODPOST

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-26 Thread Alex Ghiti
/do_mounts.o(.text+0x180): cannot reach strchr ... On 07/26/2018 12:59 PM, Helge Deller wrote: * Alex Ghiti : This is the result of the build for all arches tackled in this series rebased on 4.18-rc6: ... parisc:     generic-64bit_defconfig: with huge page does not link     generic

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-26 Thread Alex Ghiti
Hi Christophe, Sorry, I should have done it already: with and without huge page activated, the build for mpc885_ads_defconfig is OK. Thanks, Alex On 07/26/2018 03:13 PM, LEROY Christophe wrote: Alex Ghiti a écrit : Hi everyone, This is the result of the build for all arches tackled

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-25 Thread Alex Ghiti
Ellerman wrote: Alex Ghiti writes: Does anyone have any suggestion about those patches ? Cross compiling it for some non-x86 arches would be a good start :) There are cross compilers available here: https://mirrors.edge.kernel.org/pub/tools/crosstool/ cheers On 07/09/2018 02:16 PM, Michal

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-23 Thread Alex Ghiti
Ok will do and report when done. Thanks for your feedback, Alex On 07/23/2018 02:00 PM, Michael Ellerman wrote: Alex Ghiti writes: Does anyone have any suggestion about those patches ? Cross compiling it for some non-x86 arches would be a good start :) There are cross compilers available

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-20 Thread Alex Ghiti
Does anyone have any suggestion about those patches ? On 07/09/2018 02:16 PM, Michal Hocko wrote: [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-a...@ghiti.fr] On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote: In order to reduce copy/paste of functions across architectures

Re: [PATCH v3 02/11] hugetlb: Introduce generic version of hugetlb_free_pgd_range

2018-07-05 Thread Alex Ghiti
My bad, when I moved the #include at the bottom of the file, I did not pay attention to that #ifdef. I'm going to fix powerpc and check other architectures if I did not make the same mistake. I'll send a v4 as soon as possible. Thanks for your comment, Alex On 07/05/2018 10:22 AM,

Re: [PATCH 05/11] hugetlb: Introduce generic version of huge_ptep_clear_flush

2018-07-05 Thread Alex Ghiti
Please drop this serie, sorry for the noise. On 07/05/2018 04:58 AM, Alexandre Ghiti wrote: arm, x86 architectures use the same version of huge_ptep_clear_flush, so move this generic implementation into asm-generic/hugetlb.h. Signed-off-by: Alexandre Ghiti ---

Re: [PATCH v2 06/11] hugetlb: Introduce generic version of huge_pte_none

2018-07-05 Thread Alex Ghiti
Please drop this serie, sorry for the noise. On 07/05/2018 05:12 AM, Alexandre Ghiti wrote: arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures use the same version of huge_pte_none, so move this generic implementation into asm-generic/hugetlb.h. Signed-off-by: Alexandre Ghiti