* Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
From: Christophe Leroy @ 2021-04-14 5:22 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm
Cc: linux-s390, linux-ia64, linux-parisc, linux-xtensa, linux-sh,
linux-hexagon, x86, linux-um, linux-mips, linux-csky,
linux-kernel, linux-m68k, openrisc, linux-alpha, sparclinux,
linux-riscv, linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
> for those platforms which would override generic default FIRST_USER_ADDRESS
> value 0UL. This makes it much cleaner with reduced code.
>
> Cc: linux-alpha@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-csky@vger.kernel.org
> Cc: linux-hexagon@vger.kernel.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-m68k@lists.linux-m68k.org
> Cc: linux-mips@vger.kernel.org
> Cc: openrisc@lists.librecores.org
> Cc: linux-parisc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-riscv@lists.infradead.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: linux-um@lists.infradead.org
> Cc: linux-xtensa@linux-xtensa.org
> Cc: x86@kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/alpha/include/asm/pgtable.h | 1 -
> arch/arc/include/asm/pgtable.h | 6 ------
> arch/arm/Kconfig | 1 +
> arch/arm64/include/asm/pgtable.h | 2 --
> arch/csky/include/asm/pgtable.h | 1 -
> arch/hexagon/include/asm/pgtable.h | 3 ---
> arch/ia64/include/asm/pgtable.h | 1 -
> arch/m68k/include/asm/pgtable_mm.h | 1 -
> arch/microblaze/include/asm/pgtable.h | 2 --
> arch/mips/include/asm/pgtable-32.h | 1 -
> arch/mips/include/asm/pgtable-64.h | 1 -
> arch/nds32/Kconfig | 1 +
> arch/nios2/include/asm/pgtable.h | 2 --
> arch/openrisc/include/asm/pgtable.h | 1 -
> arch/parisc/include/asm/pgtable.h | 2 --
> arch/powerpc/include/asm/book3s/pgtable.h | 1 -
> arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
> arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
> arch/riscv/include/asm/pgtable.h | 2 --
> arch/s390/include/asm/pgtable.h | 2 --
> arch/sh/include/asm/pgtable.h | 2 --
> arch/sparc/include/asm/pgtable_32.h | 1 -
> arch/sparc/include/asm/pgtable_64.h | 3 ---
> arch/um/include/asm/pgtable-2level.h | 1 -
> arch/um/include/asm/pgtable-3level.h | 1 -
> arch/x86/include/asm/pgtable_types.h | 2 --
> arch/xtensa/include/asm/pgtable.h | 1 -
> include/linux/mm.h | 4 ++++
> mm/Kconfig | 4 ++++
> 29 files changed, 10 insertions(+), 43 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8ba434287387..47098ccd715e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>
> void init_mm_internals(void);
>
> +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
I guess you didn't test it ..... :)
should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
> +#define FIRST_USER_ADDRESS 0UL
> +#endif
But why do we need a config option at all for that ?
Why not just:
#ifndef FIRST_USER_ADDRESS
#define FIRST_USER_ADDRESS 0UL
#endif
> +
> #ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly */
> extern unsigned long max_mapnr;
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 24c045b24b95..373fbe377075 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -806,6 +806,10 @@ config VMAP_PFN
>
> config ARCH_USES_HIGH_VMA_FLAGS
> bool
> +
> +config ARCH_HAS_FIRST_USER_ADDRESS
> + bool
> +
> config ARCH_HAS_PKEYS
> bool
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc: Rename probe_kernel_read_inst()
From: Aneesh Kumar K.V @ 2021-04-14 5:23 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, jniethe5
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e2fbccd1a0b4e8ed7e12936e03be76588202c7a0.1618331980.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> When probe_kernel_read_inst() was created, it was to mimic
> probe_kernel_read() function.
>
> Since then, probe_kernel_read() has been renamed
> copy_from_kernel_nofault().
>
> Rename probe_kernel_read_inst() into copy_from_kernel_nofault_inst().
At first glance I read it as copy from kernel nofault instruction.
How about copy_inst_from_kernel_nofault()?
-aneesh
^ permalink raw reply
* Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
From: Anshuman Khandual @ 2021-04-14 5:59 UTC (permalink / raw)
To: Christophe Leroy, linux-mm, akpm
Cc: linux-s390, linux-ia64, linux-parisc, linux-xtensa, linux-sh,
linux-hexagon, x86, linux-um, linux-mips, linux-csky,
linux-kernel, linux-m68k, openrisc, linux-alpha, sparclinux,
linux-riscv, linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>
On 4/14/21 10:52 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>> for those platforms which would override generic default FIRST_USER_ADDRESS
>> value 0UL. This makes it much cleaner with reduced code.
>>
>> Cc: linux-alpha@vger.kernel.org
>> Cc: linux-snps-arc@lists.infradead.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-csky@vger.kernel.org
>> Cc: linux-hexagon@vger.kernel.org
>> Cc: linux-ia64@vger.kernel.org
>> Cc: linux-m68k@lists.linux-m68k.org
>> Cc: linux-mips@vger.kernel.org
>> Cc: openrisc@lists.librecores.org
>> Cc: linux-parisc@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: linux-riscv@lists.infradead.org
>> Cc: linux-s390@vger.kernel.org
>> Cc: linux-sh@vger.kernel.org
>> Cc: sparclinux@vger.kernel.org
>> Cc: linux-um@lists.infradead.org
>> Cc: linux-xtensa@linux-xtensa.org
>> Cc: x86@kernel.org
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/alpha/include/asm/pgtable.h | 1 -
>> arch/arc/include/asm/pgtable.h | 6 ------
>> arch/arm/Kconfig | 1 +
>> arch/arm64/include/asm/pgtable.h | 2 --
>> arch/csky/include/asm/pgtable.h | 1 -
>> arch/hexagon/include/asm/pgtable.h | 3 ---
>> arch/ia64/include/asm/pgtable.h | 1 -
>> arch/m68k/include/asm/pgtable_mm.h | 1 -
>> arch/microblaze/include/asm/pgtable.h | 2 --
>> arch/mips/include/asm/pgtable-32.h | 1 -
>> arch/mips/include/asm/pgtable-64.h | 1 -
>> arch/nds32/Kconfig | 1 +
>> arch/nios2/include/asm/pgtable.h | 2 --
>> arch/openrisc/include/asm/pgtable.h | 1 -
>> arch/parisc/include/asm/pgtable.h | 2 --
>> arch/powerpc/include/asm/book3s/pgtable.h | 1 -
>> arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>> arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>> arch/riscv/include/asm/pgtable.h | 2 --
>> arch/s390/include/asm/pgtable.h | 2 --
>> arch/sh/include/asm/pgtable.h | 2 --
>> arch/sparc/include/asm/pgtable_32.h | 1 -
>> arch/sparc/include/asm/pgtable_64.h | 3 ---
>> arch/um/include/asm/pgtable-2level.h | 1 -
>> arch/um/include/asm/pgtable-3level.h | 1 -
>> arch/x86/include/asm/pgtable_types.h | 2 --
>> arch/xtensa/include/asm/pgtable.h | 1 -
>> include/linux/mm.h | 4 ++++
>> mm/Kconfig | 4 ++++
>> 29 files changed, 10 insertions(+), 43 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 8ba434287387..47098ccd715e 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>> void init_mm_internals(void);
>> +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
>
> I guess you didn't test it ..... :)
In fact I did :) Though just booted it on arm64 and cross compiled on
multiple others platforms.
>
> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
Right, meant that instead.
>
>> +#define FIRST_USER_ADDRESS 0UL
>> +#endif
>
> But why do we need a config option at all for that ?
>
> Why not just:
>
> #ifndef FIRST_USER_ADDRESS
> #define FIRST_USER_ADDRESS 0UL
> #endif
This sounds simpler. But just wondering, would not there be any possibility
of build problems due to compilation sequence between arch and generic code ?
^ permalink raw reply
* Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
From: Christophe Leroy @ 2021-04-14 6:10 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm
Cc: linux-s390, linux-ia64, linux-parisc, linux-xtensa, linux-sh,
linux-hexagon, x86, linux-um, linux-mips, linux-csky,
linux-kernel, linux-m68k, openrisc, linux-alpha, sparclinux,
linux-riscv, linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <6d24d3cc-b2df-f0d7-f4bf-f505f679c77e@arm.com>
Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :
>
>
> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>
>>
>> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>>> for those platforms which would override generic default FIRST_USER_ADDRESS
>>> value 0UL. This makes it much cleaner with reduced code.
>>>
>>> Cc: linux-alpha@vger.kernel.org
>>> Cc: linux-snps-arc@lists.infradead.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-csky@vger.kernel.org
>>> Cc: linux-hexagon@vger.kernel.org
>>> Cc: linux-ia64@vger.kernel.org
>>> Cc: linux-m68k@lists.linux-m68k.org
>>> Cc: linux-mips@vger.kernel.org
>>> Cc: openrisc@lists.librecores.org
>>> Cc: linux-parisc@vger.kernel.org
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Cc: linux-riscv@lists.infradead.org
>>> Cc: linux-s390@vger.kernel.org
>>> Cc: linux-sh@vger.kernel.org
>>> Cc: sparclinux@vger.kernel.org
>>> Cc: linux-um@lists.infradead.org
>>> Cc: linux-xtensa@linux-xtensa.org
>>> Cc: x86@kernel.org
>>> Cc: linux-mm@kvack.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> arch/alpha/include/asm/pgtable.h | 1 -
>>> arch/arc/include/asm/pgtable.h | 6 ------
>>> arch/arm/Kconfig | 1 +
>>> arch/arm64/include/asm/pgtable.h | 2 --
>>> arch/csky/include/asm/pgtable.h | 1 -
>>> arch/hexagon/include/asm/pgtable.h | 3 ---
>>> arch/ia64/include/asm/pgtable.h | 1 -
>>> arch/m68k/include/asm/pgtable_mm.h | 1 -
>>> arch/microblaze/include/asm/pgtable.h | 2 --
>>> arch/mips/include/asm/pgtable-32.h | 1 -
>>> arch/mips/include/asm/pgtable-64.h | 1 -
>>> arch/nds32/Kconfig | 1 +
>>> arch/nios2/include/asm/pgtable.h | 2 --
>>> arch/openrisc/include/asm/pgtable.h | 1 -
>>> arch/parisc/include/asm/pgtable.h | 2 --
>>> arch/powerpc/include/asm/book3s/pgtable.h | 1 -
>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>>> arch/riscv/include/asm/pgtable.h | 2 --
>>> arch/s390/include/asm/pgtable.h | 2 --
>>> arch/sh/include/asm/pgtable.h | 2 --
>>> arch/sparc/include/asm/pgtable_32.h | 1 -
>>> arch/sparc/include/asm/pgtable_64.h | 3 ---
>>> arch/um/include/asm/pgtable-2level.h | 1 -
>>> arch/um/include/asm/pgtable-3level.h | 1 -
>>> arch/x86/include/asm/pgtable_types.h | 2 --
>>> arch/xtensa/include/asm/pgtable.h | 1 -
>>> include/linux/mm.h | 4 ++++
>>> mm/Kconfig | 4 ++++
>>> 29 files changed, 10 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 8ba434287387..47098ccd715e 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>>> void init_mm_internals(void);
>>> +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
>>
>> I guess you didn't test it ..... :)
>
> In fact I did :) Though just booted it on arm64 and cross compiled on
> multiple others platforms.
>
>>
>> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
>
> Right, meant that instead.
>
>>
>>> +#define FIRST_USER_ADDRESS 0UL
>>> +#endif
>>
>> But why do we need a config option at all for that ?
>>
>> Why not just:
>>
>> #ifndef FIRST_USER_ADDRESS
>> #define FIRST_USER_ADDRESS 0UL
>> #endif
>
> This sounds simpler. But just wondering, would not there be any possibility
> of build problems due to compilation sequence between arch and generic code ?
>
For sure it has to be addresses carefully, but there are already a lot of stuff like that around
pgtables.h
For instance, pte_offset_kernel() has a generic definition in linux/pgtables.h based on whether it
is already defined or not.
Taking into account that FIRST_USER_ADDRESS is today in the architectures's asm/pgtables.h, I think
putting the fallback definition in linux/pgtable.h would do the trick.
^ permalink raw reply
* Re: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
From: Stephen Rothwell @ 2021-04-14 6:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Thomas Bogendoerfer, Parisc List,
Vasily Gorbik, linuxppc-dev, Catalin Marinas, Helge Deller,
the arch/x86 maintainers, Linux Kernel Mailing List,
David S. Miller, James E.J. Bottomley, Christian Borntraeger,
Linux ARM, sparclinux, open list:BROADCOM NVRAM DRIVER,
Will Deacon, Christoph Hellwig, Heiko Carstens
In-Reply-To: <CAK8P3a2MSJarPMfJ8RrSKDMXte3KQec=+GQ-LzV6HB7-Nm1FcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
Hi Arnd,
On Mon, 12 Apr 2021 11:55:41 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> The patch looks good, but I'd like to see a description for each one.
> How about:
>
> | The check was added when Stephen Rothwell created the file, but
> | no architecture ever defined it.
Actually it was used by the xtensa architecture until Dec, 2006.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/smp: Add SD_SHARE_PKG_RESOURCES flag to MC sched-domain
From: Gautham R Shenoy @ 2021-04-14 7:00 UTC (permalink / raw)
To: Mel Gorman
Cc: Gautham R. Shenoy, Michael Neuling, Vaidyanathan Srinivasan,
Vincent Guittot, Srikar Dronamraju, Rik van Riel, LKML,
Nicholas Piggin, Dietmar Eggemann, Parth Shah, linuxppc-dev,
Valentin Schneider
In-Reply-To: <20210412152444.GA3697@techsingularity.net>
Hello Mel,
On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > Peter, Valentin, Vincent, Mel, etal
> > > >
> > > > On architectures where we have multiple levels of cache access latencies
> > > > within a DIE, (For example: one within the current LLC or SMT core and the
> > > > other at MC or Hemisphere, and finally across hemispheres), do you have any
> > > > suggestions on how we could handle the same in the core scheduler?
> >
> > I would say that SD_SHARE_PKG_RESOURCES is there for that and doesn't
> > only rely on cache
> >
>
> >From topology.c
>
> SD_SHARE_PKG_RESOURCES - describes shared caches
>
Yes, I was aware of this shared caches, but this current patch was the
simplest way to achieve the effect, though the cores in the MC domain
on POWER10 do not share a cache. However, it is relatively faster to
transfer data across the cores within the MC domain compared to the
cores outside the MC domain in the Die.
> I'm guessing here because I am not familiar with power10 but the central
> problem appears to be when to prefer selecting a CPU sharing L2 or L3
> cache and the core assumes the last-level-cache is the only relevant one.
>
On POWER we have traditionally preferred to keep the LLC at the
sched-domain comprising of groups of CPUs that share the L2 (since L3
is a victim cache on POWER).
On POWER9, the L2 was shared by the threads of a pair of SMT4 cores,
while on POWER10, L2 is shared by threads of a single SMT4 core.
Thus, the current task wake-up logic would have a lower probability of
finding an idle core inside an LLC since it has only one core to
search in the LLC. This is why moving the LLC to the parent domain
(MC) consisting of a group of SMT4 cores among which snooping the
cache-data is faster is helpful for workloads that require the single
threaded performance.
> For this patch, I wondered if setting SD_SHARE_PKG_RESOURCES would have
> unintended consequences for load balancing because load within a die may
> not be spread between SMT4 domains if SD_SHARE_PKG_RESOURCES was set at
> the MC level.
Since we are adding the SD_SHARE_PKG_RESOURCES to the parent of the
the only sched-domain (which is a SMT4 domain) which currently has
this flag set, would it cause issues in spreading the load between the
SMT4 domains ?
Are there any tests/benchmarks that can help bring this out? It could
be good to understand this.
>
> > >
> > > Minimally I think it would be worth detecting when there are multiple
> > > LLCs per node and detecting that in generic code as a static branch. In
> > > select_idle_cpu, consider taking two passes -- first on the LLC domain
> > > and if no idle CPU is found then taking a second pass if the search depth
> >
> > We have done a lot of changes to reduce and optimize the fast path and
> > I don't think re adding another layer in the fast path makes sense as
> > you will end up unrolling the for_each_domain behind some
> > static_banches.
> >
>
> Searching the node would only happen if a) there was enough search depth
> left and b) there were no idle CPUs at the LLC level. As no new domain
> is added, it's not clear to me why for_each_domain would change.
>
> But still, your comment reminded me that different architectures have
> different requirements
>
> Power 10 appears to prefer CPU selection sharing L2 cache but desires
> spillover to L3 when selecting and idle CPU.
>
Indeed, so on POWER10, the preference would be
1) idle core in the L2 domain.
2) idle core in the MC domain.
3) idle CPU in the L2 domain
4) idle CPU in the MC domain.
This patch is able to achieve this *implicitly* because of the way the
select_idle_cpu() and the select_idle_core() is currently coded, where
in the presence of idle cores in the MC level, the select_idle_core()
searches for the idle core starting with the core of the target-CPU.
If I understand your proposal correctly it would be to make this
explicit into a two level search where we first search in the LLC
domain, failing which, we carry on the search in the rest of the die
(assuming that the LLC is not in the die).
> X86 varies, it might want the Power10 approach for some families and prefer
> L3 spilling over to a CPU on the same node in others.
>
> S390 cares about something called books and drawers although I've no
> what it means as such and whether it has any preferences on
> search order.
>
> ARM has similar requirements again according to "scheduler: expose the
> topology of clusters and add cluster scheduler" and that one *does*
> add another domain.
>
> I had forgotten about the ARM patches but remembered that they were
> interesting because they potentially help the Zen situation but I didn't
> get the chance to review them before they fell off my radar again. About
> all I recall is that I thought the "cluster" terminology was vague.
>
> The only commonality I thought might exist is that architectures may
> like to define what the first domain to search for an idle CPU and a
> second domain. Alternatively, architectures could specify a domain to
> search primarily but also search the next domain in the hierarchy if
> search depth permits. The default would be the existing behaviour --
> search CPUs sharing a last-level-cache.
>
> > SD_SHARE_PKG_RESOURCES should be set to the last level where we can
> > efficiently move task between CPUs at wakeup
> >
>
> The definition of "efficiently" varies. Moving tasks between CPUs sharing
> a cache is most efficient but moving the task to a CPU that at least has
> local memory channels is a reasonable option if there are no idle CPUs
> sharing cache and preferable to stacking.
>
> > > allows within the node with the LLC CPUs masked out. While there would be
> > > a latency hit because cache is not shared, it would still be a CPU local
> > > to memory that is idle. That would potentially be beneficial on Zen*
> > > as well without having to introduce new domains in the topology hierarchy.
> >
> > What is the current sched_domain topology description for zen ?
> >
>
> The cache and NUMA topologies differ slightly between each generation
> of Zen. The common pattern is that a single NUMA node can have multiple
> L3 caches and at one point I thought it might be reasonable to allow
> spillover to select a local idle CPU instead of stacking multiple tasks
> on a CPU sharing cache. I never got as far as thinking how it could be
> done in a way that multiple architectures would be happy with.
In case of Zen, do we have multiple cores sharing the L3 cache ? Are
these modelled as a separate sched-domain ?
>
> --
> Mel Gorman
> SUSE Labs
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/smp: Add SD_SHARE_PKG_RESOURCES flag to MC sched-domain
From: Gautham R Shenoy @ 2021-04-14 7:02 UTC (permalink / raw)
To: Michal Suchánek
Cc: Gautham R. Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Rik van Riel, linuxppc-dev, LKML,
Nicholas Piggin, Valentin Schneider, Parth Shah,
Vaidyanathan Srinivasan, Mel Gorman, Dietmar Eggemann
In-Reply-To: <20210412163355.GV6564@kitsune.suse.cz>
On Mon, Apr 12, 2021 at 06:33:55PM +0200, Michal Suchánek wrote:
> On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> > On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > > Peter, Valentin, Vincent, Mel, etal
> > > > >
> > > > > On architectures where we have multiple levels of cache access latencies
> > > > > within a DIE, (For example: one within the current LLC or SMT core and the
> > > > > other at MC or Hemisphere, and finally across hemispheres), do you have any
> > > > > suggestions on how we could handle the same in the core scheduler?
> > >
> > > I would say that SD_SHARE_PKG_RESOURCES is there for that and doesn't
> > > only rely on cache
> > >
> >
> > From topology.c
> >
> > SD_SHARE_PKG_RESOURCES - describes shared caches
> >
> > I'm guessing here because I am not familiar with power10 but the central
> > problem appears to be when to prefer selecting a CPU sharing L2 or L3
> > cache and the core assumes the last-level-cache is the only relevant one.
>
> It does not seem to be the case according to original description:
>
> >>>> When the scheduler tries to wakeup a task, it chooses between the
> >>>> waker-CPU and the wakee's previous-CPU. Suppose this choice is called
> >>>> the "target", then in the target's LLC domain, the scheduler
> >>>>
> >>>> a) tries to find an idle core in the LLC. This helps exploit the
> This is the same as (b) Should this be SMT^^^ ?
On POWER10, without this patch, the LLC is at SMT sched-domain
domain. The difference between a) and b) is a) searches for an idle
core, while b) searches for an idle CPU.
> >>>> SMT folding that the wakee task can benefit from. If an idle
> >>>> core is found, the wakee is woken up on it.
> >>>>
> >>>> b) Failing to find an idle core, the scheduler tries to find an idle
> >>>> CPU in the LLC. This helps minimise the wakeup latency for the
> >>>> wakee since it gets to run on the CPU immediately.
> >>>>
> >>>> c) Failing this, it will wake it up on target CPU.
> >>>>
> >>>> Thus, with P9-sched topology, since the CACHE domain comprises of two
> >>>> SMT4 cores, there is a decent chance that we get an idle core, failing
> >>>> which there is a relatively higher probability of finding an idle CPU
> >>>> among the 8 threads in the domain.
> >>>>
> >>>> However, in P10-sched topology, since the SMT domain is the LLC and it
> >>>> contains only a single SMT4 core, the probability that we find that
> >>>> core to be idle is less. Furthermore, since there are only 4 CPUs to
> >>>> search for an idle CPU, there is lower probability that we can get an
> >>>> idle CPU to wake up the task on.
>
> >
> > For this patch, I wondered if setting SD_SHARE_PKG_RESOURCES would have
> > unintended consequences for load balancing because load within a die may
> > not be spread between SMT4 domains if SD_SHARE_PKG_RESOURCES was set at
> > the MC level.
>
> Not spreading load between SMT4 domains within MC is exactly what setting LLC
> at MC level would address, wouldn't it?
>
> As in on P10 we have two relevant levels but the topology as is describes only
> one, and moving the LLC level lower gives two levels the scheduler looks at
> again. Or am I missing something?
This is my current understanding as well, since with this patch we
would then be able to move tasks quickly between the SMT4 cores,
perhaps at the expense of losing out on cache-affinity. Which is why
it would be good to verify this using a test/benchmark.
>
> Thanks
>
> Michal
>
--
Thanks and Regards
gautham.
^ permalink raw reply
* Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
From: Jesper Dangaard Brouer @ 2021-04-14 8:10 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Arnd Bergmann, Grygorii Strashko, netdev, Ilias Apalodimas,
linux-mips, linux-kernel, linux-mm, brouer, Matteo Croce,
linuxppc-dev, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20210412011532.GG2531743@casper.infradead.org>
On Mon, 12 Apr 2021 02:15:32 +0100
Matthew Wilcox <willy@infradead.org> wrote:
> On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> > Basically, we have three aligned dwords here. We can either alias with
> > @flags and the first word of @lru, or the second word of @lru and @mapping,
> > or @index and @private. @flags is a non-starter. If we use @mapping,
> > then you have to set it to NULL before you free it, and I'm not sure
> > how easy that will be for you. If that's trivial, then we could use
> > the layout:
> >
> > unsigned long _pp_flags;
> > unsigned long pp_magic;
> > union {
> > dma_addr_t dma_addr; /* might be one or two words */
> > unsigned long _pp_align[2];
> > };
> > unsigned long pp_pfmemalloc;
> > unsigned long xmi;
>
> I forgot about the munmap path. That calls zap_page_range() which calls
> set_page_dirty() which calls page_mapping(). If we use page->mapping,
> that's going to get interpreted as an address_space pointer.
>
> *sigh*. Foiled at every turn.
Yes, indeed! - And very frustrating. It's keeping me up at night.
I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
me that I don't sleep well with these kind of dreams ;-)
> I'm kind of inclined towards using two (or more) bits for PageSlab as
> we discussed here:
>
> https://lore.kernel.org/linux-mm/01000163efe179fe-d6270c58-eaba-482f-a6bd-334667250ef7-000000@email.amazonses.com/
>
> so we have PageKAlloc that's true for PageSlab, PagePool, PageDMAPool,
> PageVMalloc, PageFrag and maybe a few other kernel-internal allocations.
I actually like this idea a lot. I also think it will solve or remove
Matteo/Ilias'es[2] need to introduce the pp_magic signature. Ilias do
say[1] that page_pool pages could be used for TCP RX zerocopy, but I
don't think we should "allow" that (meaning page_pool should drop the
DMA-mapping and give up recycling). I should argue why in that thread.
That said, I think we need to have a quicker fix for the immediate
issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
it leaves[3] in struct page. In[3] you mention ppc32, does it only
happens on certain 32-bit archs?
I'm seriously considering removing page_pool's support for doing/keeping
DMA-mappings on 32-bit arch's. AFAIK only a single driver use this.
> (see also here:)
> https://lore.kernel.org/linux-mm/20180518194519.3820-18-willy@infradead.org/
[1] https://lore.kernel.org/netdev/YHHuE7g73mZNrMV4@enceladus/
[2] https://patchwork.kernel.org/project/netdevbpf/patch/20210409223801.104657-3-mcroce@linux.microsoft.com/
[3] https://lore.kernel.org/linux-mm/20210410024313.GX2531743@casper.infradead.org/
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v2] powerpc/eeh: Fix EEH handling for hugepages in ioremap space.
From: Mahesh J Salgaonkar @ 2021-04-14 8:31 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: linuxppc-dev, stable, Aneesh Kumar K.V
In-Reply-To: <CAOSf1CG3oYCnWx+gV3VgYzkQJTvVEeMGDyKjMAQRdH8w23C2QA@mail.gmail.com>
On 2021-04-13 10:53:39 Tue, Oliver O'Halloran wrote:
> On Mon, Apr 12, 2021 at 5:52 PM Mahesh Salgaonkar <mahesh@linux.ibm.com> wrote:
> >
> > During the EEH MMIO error checking, the current implementation fails to map
> > the (virtual) MMIO address back to the pci device on radix with hugepage
> > mappings for I/O. This results into failure to dispatch EEH event with no
> > recovery even when EEH capability has been enabled on the device.
> >
> > eeh_check_failure(token) # token = virtual MMIO address
> > addr = eeh_token_to_phys(token);
> > edev = eeh_addr_cache_get_dev(addr);
> > if (!edev)
> > return 0;
> > eeh_dev_check_failure(edev); <= Dispatch the EEH event
> >
> > In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys
> > translation that results in wrong physical address, which is then passed to
> > eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges
> > to get to a PCI device. Hence, it fails to find a match and the EEH event
> > never gets dispatched leaving the device in failed state.
> >
> > The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space")
> > introduced following logic to translate virt to phys for hugepage mappings:
> >
> > eeh_token_to_phys():
> > + pa = pte_pfn(*ptep);
> > +
> > + /* On radix we can do hugepage mappings for io, so handle that */
> > + if (hugepage_shift) {
> > + pa <<= hugepage_shift; <= This is wrong
> > + pa |= token & ((1ul << hugepage_shift) - 1);
> > + }
>
> I think I vaguely remember thinking "is this right?" at the time.
> Apparently not!
>
> Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
>
Thanks for the review.
>
> It would probably be a good idea to add a debugfs interface to help
> with testing the address translation. Maybe something like:
>
> echo <mmio addr> > /sys/kernel/debug/powerpc/eeh_addr_check
>
> Then in the kernel:
>
> struct resource *r = lookup_resource(mmio_addr);
> void *virt = ioremap_resource(r);
> ret = eeh_check_failure(virt);
> iounmap(virt)
>
> return ret;
>
> A little tedious, but then you can write a selftest :)
Sure, will give a try.
Thanks,
-Mahesh.
--
Mahesh J Salgaonkar
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] of: net: pass the dst buffer to of_get_mac_address()
From: Dan Carpenter @ 2021-04-14 5:33 UTC (permalink / raw)
To: kbuild, Michael Walle, ath9k-devel, UNGLinuxDriver,
linux-arm-kernel, linux-kernel, linuxppc-dev, netdev,
linux-mediatek, linux-renesas-soc, linux-stm32, linux-amlogic
Cc: kbuild-all, lkp
In-Reply-To: <20210406153725.10059-2-michael@walle.cc>
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]
Hi Michael,
url: https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git cc0626c2aaed8e475efdd85fa374b497a7192e35
config: x86_64-randconfig-m001-20210406 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2069 axienet_probe() warn: passing a valid pointer to 'PTR_ERR'
vim +/PTR_ERR +2069 drivers/net/ethernet/xilinx/xilinx_axienet_main.c
522856cefaf09d Robert Hancock 2019-06-06 2060 /* Check for Ethernet core IRQ (optional) */
522856cefaf09d Robert Hancock 2019-06-06 2061 if (lp->eth_irq <= 0)
522856cefaf09d Robert Hancock 2019-06-06 2062 dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
522856cefaf09d Robert Hancock 2019-06-06 2063
8a3b7a252dca9f Daniel Borkmann 2012-01-19 2064 /* Retrieve the MAC address */
411b125c6ace1f Michael Walle 2021-04-06 2065 ret = of_get_mac_address(pdev->dev.of_node, mac_addr);
411b125c6ace1f Michael Walle 2021-04-06 2066 if (!ret) {
411b125c6ace1f Michael Walle 2021-04-06 2067 axienet_set_mac_address(ndev, mac_addr);
411b125c6ace1f Michael Walle 2021-04-06 2068 } else {
d05a9ed5c3a773 Robert Hancock 2019-06-06 @2069 dev_warn(&pdev->dev, "could not find MAC address property: %ld\n",
d05a9ed5c3a773 Robert Hancock 2019-06-06 2070 PTR_ERR(mac_addr));
^^^^^^^^^^^^^^^^^
This should print "ret".
411b125c6ace1f Michael Walle 2021-04-06 2071 axienet_set_mac_address(ndev, NULL);
8a3b7a252dca9f Daniel Borkmann 2012-01-19 2072 }
8a3b7a252dca9f Daniel Borkmann 2012-01-19 2073
8a3b7a252dca9f Daniel Borkmann 2012-01-19 2074 lp->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
8a3b7a252dca9f Daniel Borkmann 2012-01-19 2075 lp->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31129 bytes --]
^ permalink raw reply
* [PATCH] init: consolidate trap_init()
From: Jisheng Zhang @ 2021-04-14 8:58 UTC (permalink / raw)
To: Vineet Gupta, Russell King, Yoshinori Sato, Brian Cain, Nick Hu,
Greentime Hu, Vincent Chen, Ley Foon Tan, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Jeff Dike, Richard Weinberger, Anton Ivanov
Cc: uclinux-h8-devel, linux-parisc, linux-hexagon, linux-um,
linux-kernel, openrisc, Anup Patel, linux-riscv, linux-snps-arc,
linuxppc-dev, linux-arm-kernel
Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arc/kernel/traps.c | 5 -----
arch/arm/kernel/traps.c | 5 -----
arch/h8300/kernel/traps.c | 13 -------------
arch/hexagon/kernel/traps.c | 4 ----
arch/nds32/kernel/traps.c | 5 -----
arch/nios2/kernel/traps.c | 5 -----
arch/openrisc/kernel/traps.c | 5 -----
arch/parisc/kernel/traps.c | 4 ----
arch/powerpc/kernel/traps.c | 5 -----
arch/riscv/kernel/traps.c | 5 -----
arch/um/kernel/trap.c | 4 ----
init/main.c | 2 ++
12 files changed, 2 insertions(+), 60 deletions(-)
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 57235e5c0cea..6b83e3f2b41c 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -20,11 +20,6 @@
#include <asm/unaligned.h>
#include <asm/kprobes.h>
-void __init trap_init(void)
-{
- return;
-}
-
void die(const char *str, struct pt_regs *regs, unsigned long address)
{
show_kernel_fault_diag(str, regs, address);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 17d5a785df28..9baccef20392 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -780,11 +780,6 @@ void abort(void)
panic("Oops failed to kill thread");
}
-void __init trap_init(void)
-{
- return;
-}
-
#ifdef CONFIG_KUSER_HELPERS
static void __init kuser_init(void *vectors)
{
diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index 5d8b969cd8f3..c3a3ebf77fbb 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -30,19 +30,6 @@
static DEFINE_SPINLOCK(die_lock);
-/*
- * this must be called very early as the kernel might
- * use some instruction that are emulated on the 060
- */
-
-void __init base_trap_init(void)
-{
-}
-
-void __init trap_init(void)
-{
-}
-
asmlinkage void set_esp0(unsigned long ssp)
{
current->thread.esp0 = ssp;
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 904134b37232..edfc35dafeb1 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -28,10 +28,6 @@
#define TRAP_SYSCALL 1
#define TRAP_DEBUG 0xdb
-void __init trap_init(void)
-{
-}
-
#ifdef CONFIG_GENERIC_BUG
/* Maybe should resemble arch/sh/kernel/traps.c ?? */
int is_valid_bugaddr(unsigned long addr)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index ee0d9ae192a5..f06421c645af 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -183,11 +183,6 @@ void __pgd_error(const char *file, int line, unsigned long val)
}
extern char *exception_vector, *exception_vector_end;
-void __init trap_init(void)
-{
- return;
-}
-
void __init early_trap_init(void)
{
unsigned long ivb = 0;
diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index b172da4eb1a9..596986a74a26 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -105,11 +105,6 @@ void show_stack(struct task_struct *task, unsigned long *stack,
printk("%s\n", loglvl);
}
-void __init trap_init(void)
-{
- /* Nothing to do here */
-}
-
/* Breakpoint handler */
asmlinkage void breakpoint_c(struct pt_regs *fp)
{
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 4d61333c2623..aa1e709405ac 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -231,11 +231,6 @@ void unhandled_exception(struct pt_regs *regs, int ea, int vector)
die("Oops", regs, 9);
}
-void __init trap_init(void)
-{
- /* Nothing needs to be done */
-}
-
asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
{
force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->pc);
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 8d8441d4562a..747c328fb886 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -859,7 +859,3 @@ void __init early_trap_init(void)
initialize_ivt(&fault_vector_20);
}
-
-void __init trap_init(void)
-{
-}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a44a30b0688c..e952bee89684 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2207,11 +2207,6 @@ DEFINE_INTERRUPT_HANDLER(kernel_bad_stack)
die("Bad kernel stack pointer", regs, SIGABRT);
}
-void __init trap_init(void)
-{
-}
-
-
#ifdef CONFIG_PPC_EMULATED_STATS
#define WARN_EMULATED_SETUP(type) .type = { .name = #type }
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 0879b5df11b9..b3f3d84de779 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -194,8 +194,3 @@ int is_valid_bugaddr(unsigned long pc)
return ((insn & __COMPRESSED_INSN_MASK) == __BUG_INSN_16);
}
#endif /* CONFIG_GENERIC_BUG */
-
-/* stvec & scratch is already set from head.S */
-void trap_init(void)
-{
-}
diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index ad12f78bda7e..3198c4767387 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -311,7 +311,3 @@ void winch(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs)
{
do_IRQ(WINCH_IRQ, regs);
}
-
-void trap_init(void)
-{
-}
diff --git a/init/main.c b/init/main.c
index 53b278845b88..4bdbe2928530 100644
--- a/init/main.c
+++ b/init/main.c
@@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
}
#endif
+void __init __weak trap_init(void) { }
+
/* Report memory auto-initialization states for this boot. */
static void __init report_meminit(void)
{
--
2.31.0
^ permalink raw reply related
* [PATCH v4 0/9] Speedup mremap on ppc64
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
Hi,
This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
the platform to support updating higher-level page tables without
updating page table entries. This also needs to invalidate the Page Walk
Cache on architecture supporting the same.
Changes from v3:
* Fix build error reported by kernel test robot
* Address review feedback.
Changes from v2:
* switch from using mmu_gather to flush_pte_tlb_pwc_range()
Changes from v1:
* Rebase to recent upstream
* Fix build issues with tlb_gather_mmu changes
Aneesh Kumar K.V (9):
selftest/mremap_test: Update the test to handle pagesize other than 4K
selftest/mremap_test: Avoid crash with static build
mm/mremap: Use pmd/pud_poplulate to update page table entries
powerpc/mm/book3s64: Fix possible build error
powerpc/mm/book3s64: Update tlb flush routines to take a page walk
cache flush argument
mm/mremap: Use range flush that does TLB and page walk cache flush
mm/mremap: Move TLB flush outside page table lock
mm/mremap: Allow arch runtime override
powerpc/mm: Enable move pmd/pud
.../include/asm/book3s/64/tlbflush-radix.h | 19 +--
arch/powerpc/include/asm/book3s/64/tlbflush.h | 30 ++++-
arch/powerpc/include/asm/tlb.h | 6 +
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +-
arch/powerpc/mm/book3s64/radix_tlb.c | 55 ++++----
arch/powerpc/platforms/Kconfig.cputype | 2 +
mm/mremap.c | 41 ++++--
tools/testing/selftests/vm/mremap_test.c | 118 ++++++++++--------
8 files changed, 172 insertions(+), 103 deletions(-)
--
2.30.2
^ permalink raw reply
* [PATCH v4 1/9] selftest/mremap_test: Update the test to handle pagesize other than 4K
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 113 ++++++++++++-----------
1 file changed, 61 insertions(+), 52 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index 9c391d016922..c9a5461eb786 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -45,14 +45,15 @@ enum {
_4MB = 4ULL << 20,
_1GB = 1ULL << 30,
_2GB = 2ULL << 30,
- PTE = _4KB,
PMD = _2MB,
PUD = _1GB,
};
+#define PTE page_size
+
#define MAKE_TEST(source_align, destination_align, size, \
overlaps, should_fail, test_name) \
-{ \
+(struct test){ \
.name = test_name, \
.config = { \
.src_alignment = source_align, \
@@ -252,12 +253,17 @@ static int parse_args(int argc, char **argv, unsigned int *threshold_mb,
return 0;
}
+#define MAX_TEST 13
+#define MAX_PERF_TEST 3
int main(int argc, char **argv)
{
int failures = 0;
int i, run_perf_tests;
unsigned int threshold_mb = VALIDATION_DEFAULT_THRESHOLD;
unsigned int pattern_seed;
+ struct test test_cases[MAX_TEST];
+ struct test perf_test_cases[MAX_PERF_TEST];
+ int page_size;
time_t t;
pattern_seed = (unsigned int) time(&t);
@@ -268,56 +274,59 @@ int main(int argc, char **argv)
ksft_print_msg("Test configs:\n\tthreshold_mb=%u\n\tpattern_seed=%u\n\n",
threshold_mb, pattern_seed);
- struct test test_cases[] = {
- /* Expected mremap failures */
- MAKE_TEST(_4KB, _4KB, _4KB, OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source and Destination Regions Overlapping"),
- MAKE_TEST(_4KB, _1KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Destination Address Misaligned (1KB-aligned)"),
- MAKE_TEST(_1KB, _4KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source Address Misaligned (1KB-aligned)"),
-
- /* Src addr PTE aligned */
- MAKE_TEST(PTE, PTE, _8KB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "8KB mremap - Source PTE-aligned, Destination PTE-aligned"),
-
- /* Src addr 1MB aligned */
- MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination PTE-aligned"),
- MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned"),
-
- /* Src addr PMD aligned */
- MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PMD-aligned"),
-
- /* Src addr PUD aligned */
- MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
-
- struct test perf_test_cases[] = {
- /*
- * mremap 1GB region - Page table level aligned time
- * comparison.
- */
- MAKE_TEST(PTE, PTE, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PTE-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PMD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
+ page_size = sysconf(_SC_PAGESIZE);
+
+ /* Expected mremap failures */
+ test_cases[0] = MAKE_TEST(page_size, page_size, page_size,
+ OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source and Destination Regions Overlapping");
+
+ test_cases[1] = MAKE_TEST(page_size, page_size/4, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Destination Address Misaligned (1KB-aligned)");
+ test_cases[2] = MAKE_TEST(page_size/4, page_size, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source Address Misaligned (1KB-aligned)");
+
+ /* Src addr PTE aligned */
+ test_cases[3] = MAKE_TEST(PTE, PTE, PTE * 2,
+ NON_OVERLAPPING, EXPECT_SUCCESS,
+ "8KB mremap - Source PTE-aligned, Destination PTE-aligned");
+
+ /* Src addr 1MB aligned */
+ test_cases[4] = MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination PTE-aligned");
+ test_cases[5] = MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned");
+
+ /* Src addr PMD aligned */
+ test_cases[6] = MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PTE-aligned");
+ test_cases[7] = MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination 1MB-aligned");
+ test_cases[8] = MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PMD-aligned");
+
+ /* Src addr PUD aligned */
+ test_cases[9] = MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PTE-aligned");
+ test_cases[10] = MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination 1MB-aligned");
+ test_cases[11] = MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PMD-aligned");
+ test_cases[12] = MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PUD-aligned");
+
+ perf_test_cases[0] = MAKE_TEST(page_size, page_size, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PTE-aligned, Destination PTE-aligned");
+ /*
+ * mremap 1GB region - Page table level aligned time
+ * comparison.
+ */
+ perf_test_cases[1] = MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PMD-aligned, Destination PMD-aligned");
+ perf_test_cases[2] = MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PUD-aligned, Destination PUD-aligned");
run_perf_tests = (threshold_mb == VALIDATION_NO_THRESHOLD) ||
(threshold_mb * _1MB >= _1GB);
--
2.30.2
^ permalink raw reply related
* [PATCH v4 2/9] selftest/mremap_test: Avoid crash with static build
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index c9a5461eb786..0624d1bd71b5 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -75,9 +75,10 @@ static void *get_source_mapping(struct config c)
retry:
addr += c.src_alignment;
src_addr = mmap((void *) addr, c.region_size, PROT_READ | PROT_WRITE,
- MAP_FIXED | MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+ MAP_FIXED_NOREPLACE | MAP_ANONYMOUS | MAP_SHARED,
+ -1, 0);
if (src_addr == MAP_FAILED) {
- if (errno == EPERM)
+ if (errno == EPERM || errno == EEXIST)
goto retry;
goto error;
}
--
2.30.2
^ permalink raw reply related
* [PATCH v4 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index ec8f840399ed..574287f9bb39 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -26,6 +26,7 @@
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
#include "internal.h"
@@ -257,9 +258,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd_clear(old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
+ pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- /* Set the new pmd */
- set_pmd_at(mm, new_addr, new_pmd, pmd);
flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
@@ -306,8 +306,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
- /* Set the new pud */
- set_pud_at(mm, new_addr, new_pud, pud);
+ pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
--
2.30.2
^ permalink raw reply related
* [PATCH v4 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
.../include/asm/book3s/64/tlbflush-radix.h | 19 +++++++-----
arch/powerpc/include/asm/book3s/64/tlbflush.h | 23 ++++++++++++---
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +--
arch/powerpc/mm/book3s64/radix_tlb.c | 29 +++++++------------
4 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 8b33601cdb9d..171441a43b35 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -56,15 +56,18 @@ static inline void radix__flush_all_lpid_guest(unsigned int lpid)
}
#endif
-extern void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end);
-extern void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize);
-extern void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end);
-extern void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
+void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ bool flush_pwc);
+void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ bool flush_pwc);
+void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
+ unsigned long end, int psize, bool flush_pwc);
+void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end);
-extern void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end);
+void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end);
+
extern void radix__local_flush_tlb_mm(struct mm_struct *mm);
extern void radix__local_flush_all_mm(struct mm_struct *mm);
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 215973b4cb26..f9f8a3a264f7 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -45,13 +45,30 @@ static inline void tlbiel_all_lpid(bool radix)
hash__tlbiel_all(TLB_INVAL_SCOPE_LPID);
}
+static inline void flush_pmd_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ bool flush_pwc)
+{
+ if (radix_enabled())
+ return radix__flush_pmd_tlb_range(vma, start, end, flush_pwc);
+ return hash__flush_tlb_range(vma, start, end);
+}
#define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
+{
+ return flush_pmd_tlb_pwc_range(vma, start, end, false);
+}
+
+static inline void flush_hugetlb_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ bool flush_pwc)
{
if (radix_enabled())
- return radix__flush_pmd_tlb_range(vma, start, end);
+ return radix__flush_hugetlb_tlb_range(vma, start, end, flush_pwc);
return hash__flush_tlb_range(vma, start, end);
}
@@ -60,9 +77,7 @@ static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
unsigned long start,
unsigned long end)
{
- if (radix_enabled())
- return radix__flush_hugetlb_tlb_range(vma, start, end);
- return hash__flush_tlb_range(vma, start, end);
+ return flush_hugetlb_tlb_pwc_range(vma, start, end, false);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
diff --git a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
index cb91071eef52..e62f5679b119 100644
--- a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
+++ b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
@@ -26,13 +26,13 @@ void radix__local_flush_hugetlb_page(struct vm_area_struct *vma, unsigned long v
}
void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma, unsigned long start,
- unsigned long end)
+ unsigned long end, bool flush_pwc)
{
int psize;
struct hstate *hstate = hstate_file(vma->vm_file);
psize = hstate_get_psize(hstate);
- radix__flush_tlb_range_psize(vma->vm_mm, start, end, psize);
+ radix__flush_tlb_pwc_range_psize(vma->vm_mm, start, end, psize, flush_pwc);
}
/*
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 817a02ef6032..5a59e19f9e53 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -1090,7 +1090,7 @@ void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
{
#ifdef CONFIG_HUGETLB_PAGE
if (is_vm_hugetlb_page(vma))
- return radix__flush_hugetlb_tlb_range(vma, start, end);
+ return radix__flush_hugetlb_tlb_range(vma, start, end, false);
#endif
__radix__flush_tlb_range(vma->vm_mm, start, end);
@@ -1151,9 +1151,6 @@ void radix__flush_all_lpid_guest(unsigned int lpid)
_tlbie_lpid_guest(lpid, RIC_FLUSH_ALL);
}
-static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize);
-
void radix__tlb_flush(struct mmu_gather *tlb)
{
int psize = 0;
@@ -1177,10 +1174,8 @@ void radix__tlb_flush(struct mmu_gather *tlb)
else
radix__flush_all_mm(mm);
} else {
- if (!tlb->freed_tables)
- radix__flush_tlb_range_psize(mm, start, end, psize);
- else
- radix__flush_tlb_pwc_range_psize(mm, start, end, psize);
+ radix__flush_tlb_pwc_range_psize(mm, start,
+ end, psize, tlb->freed_tables);
}
}
@@ -1254,16 +1249,10 @@ static void __radix__flush_tlb_range_psize(struct mm_struct *mm,
preempt_enable();
}
-void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize)
+void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
+ unsigned long end, int psize, bool flush_pwc)
{
- return __radix__flush_tlb_range_psize(mm, start, end, psize, false);
-}
-
-static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize)
-{
- __radix__flush_tlb_range_psize(mm, start, end, psize, true);
+ __radix__flush_tlb_range_psize(mm, start, end, psize, flush_pwc);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -1315,9 +1304,11 @@ void radix__flush_tlb_collapsed_pmd(struct mm_struct *mm, unsigned long addr)
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ bool flush_pwc)
{
- radix__flush_tlb_range_psize(vma->vm_mm, start, end, MMU_PAGE_2M);
+ __radix__flush_tlb_range_psize(vma->vm_mm, start,
+ end, MMU_PAGE_2M, flush_pwc);
}
EXPORT_SYMBOL(radix__flush_pmd_tlb_range);
--
2.30.2
^ permalink raw reply related
* [PATCH v4 4/9] powerpc/mm/book3s64: Fix possible build error
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Update _tlbiel_pid() such that we can avoid build errors like below when
using this function in other places.
arch/powerpc/mm/book3s64/radix_tlb.c: In function ‘__radix__flush_tlb_range_psize’:
arch/powerpc/mm/book3s64/radix_tlb.c:114:2: warning: ‘asm’ operand 3 probably does not match constraints
114 | asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
| ^~~
arch/powerpc/mm/book3s64/radix_tlb.c:114:2: error: impossible constraint in ‘asm’
make[4]: *** [scripts/Makefile.build:271: arch/powerpc/mm/book3s64/radix_tlb.o] Error 1
m
With this fix, we can also drop the __always_inline in __radix_flush_tlb_range_psize
which was added by commit e12d6d7d46a6 ("powerpc/mm/radix: mark __radix__flush_tlb_range_psize() as __always_inline")
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/radix_tlb.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 409e61210789..817a02ef6032 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -291,22 +291,30 @@ static inline void fixup_tlbie_lpid(unsigned long lpid)
/*
* We use 128 set in radix mode and 256 set in hpt mode.
*/
-static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
+static inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
{
int set;
asm volatile("ptesync": : :"memory");
- /*
- * Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
- * also flush the entire Page Walk Cache.
- */
- __tlbiel_pid(pid, 0, ric);
+ switch (ric) {
+ case RIC_FLUSH_PWC:
- /* For PWC, only one flush is needed */
- if (ric == RIC_FLUSH_PWC) {
+ /* For PWC, only one flush is needed */
+ __tlbiel_pid(pid, 0, RIC_FLUSH_PWC);
ppc_after_tlbiel_barrier();
return;
+ case RIC_FLUSH_TLB:
+ __tlbiel_pid(pid, 0, RIC_FLUSH_TLB);
+ break;
+ case RIC_FLUSH_ALL:
+ default:
+ /*
+ * Flush the first set of the TLB, and if
+ * we're doing a RIC_FLUSH_ALL, also flush
+ * the entire Page Walk Cache.
+ */
+ __tlbiel_pid(pid, 0, RIC_FLUSH_ALL);
}
if (!cpu_has_feature(CPU_FTR_ARCH_31)) {
@@ -1176,7 +1184,7 @@ void radix__tlb_flush(struct mmu_gather *tlb)
}
}
-static __always_inline void __radix__flush_tlb_range_psize(struct mm_struct *mm,
+static void __radix__flush_tlb_range_psize(struct mm_struct *mm,
unsigned long start, unsigned long end,
int psize, bool also_pwc)
{
--
2.30.2
^ permalink raw reply related
* [PATCH v4 6/9] mm/mremap: Use range flush that does TLB and page walk cache flush
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Some architectures do have the concept of page walk cache which need
to be flush when updating higher levels of page tables. A fast mremap
that involves moving page table pages instead of copying pte entries
should flush page walk cache since the old translation cache is no more
valid.
Add new helper flush_pte_tlb_pwc_range() which invalidates both TLB and
page walk cache where TLB entries are mapped with page size PAGE_SIZE.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/book3s/64/tlbflush.h | 11 +++++++++++
mm/mremap.c | 15 +++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index f9f8a3a264f7..c236b66f490b 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -80,6 +80,17 @@ static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
return flush_hugetlb_tlb_pwc_range(vma, start, end, false);
}
+#define flush_pte_tlb_pwc_range flush_tlb_pwc_range
+static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ bool also_pwc)
+{
+ if (radix_enabled())
+ return radix__flush_tlb_pwc_range_psize(vma->vm_mm, start,
+ end, mmu_virtual_psize, also_pwc);
+ return hash__flush_tlb_range(vma, start, end);
+}
+
static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
diff --git a/mm/mremap.c b/mm/mremap.c
index 574287f9bb39..0e7b11daafee 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -210,6 +210,17 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
drop_rmap_locks(vma);
}
+#ifndef flush_pte_tlb_pwc_range
+#define flush_pte_tlb_pwc_range flush_pte_tlb_pwc_range
+static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ bool also_pwc)
+{
+ return flush_tlb_range(vma, start, end);
+}
+#endif
+
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
@@ -260,7 +271,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PMD_SIZE, true);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
@@ -307,7 +318,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
- flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PUD_SIZE, true);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
--
2.30.2
^ permalink raw reply related
* [PATCH v4 7/9] mm/mremap: Move TLB flush outside page table lock
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Move TLB flush outside page table lock so that kernel does
less with page table lock held. Releasing the ptl with old
TLB contents still valid will behave such that such access
happened before the level3 or level2 entry update.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 0e7b11daafee..7ac1df8e6d51 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -259,7 +259,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pmd_lock(vma->vm_mm, old_pmd);
+ old_ptl = pmd_lock(mm, old_pmd);
new_ptl = pmd_lockptr(mm, new_pmd);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -271,11 +271,11 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PMD_SIZE, true);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PMD_SIZE, true);
return true;
}
#else
@@ -306,7 +306,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pud_lock(vma->vm_mm, old_pud);
+ old_ptl = pud_lock(mm, old_pud);
new_ptl = pud_lockptr(mm, new_pud);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -318,11 +318,11 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
- flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PUD_SIZE, true);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PUD_SIZE, true);
return true;
}
#else
--
2.30.2
^ permalink raw reply related
* [PATCH v4 8/9] mm/mremap: Allow arch runtime override
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
Architectures like ppc64 support faster mremap only with radix
translation. Hence allow a runtime check w.r.t support for fast mremap.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/tlb.h | 6 ++++++
mm/mremap.c | 15 ++++++++++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 160422a439aa..058918a7cd3c 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -83,5 +83,11 @@ static inline int mm_is_thread_local(struct mm_struct *mm)
}
#endif
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return radix_enabled();
+}
+
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_TLB_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 7ac1df8e6d51..6922e161928c 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -25,7 +25,7 @@
#include <linux/userfaultfd_k.h>
#include <asm/cacheflush.h>
-#include <asm/tlbflush.h>
+#include <asm/tlb.h>
#include <asm/pgalloc.h>
#include "internal.h"
@@ -221,6 +221,15 @@ static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
}
#endif
+#ifndef arch_supports_page_tables_move
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return IS_ENABLED(CONFIG_HAVE_MOVE_PMD) ||
+ IS_ENABLED(CONFIG_HAVE_MOVE_PUD);
+}
+#endif
+
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
@@ -229,6 +238,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
struct mm_struct *mm = vma->vm_mm;
pmd_t pmd;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pmd shouldn't be established, free_pgtables()
* should have released it.
@@ -295,6 +306,8 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
struct mm_struct *mm = vma->vm_mm;
pud_t pud;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pud shouldn't be established, free_pgtables()
* should have released it.
--
2.30.2
^ permalink raw reply related
* [PATCH v4 9/9] powerpc/mm: Enable move pmd/pud
From: Aneesh Kumar K.V @ 2021-04-14 8:59 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: kaleshsingh, npiggin, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210414085915.301189-1-aneesh.kumar@linux.ibm.com>
mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
1GB mremap - Source PTE-aligned, Destination PTE-aligned
mremap time: 1127034ns
1GB mremap - Source PMD-aligned, Destination PMD-aligned
mremap time: 508817ns
1GB mremap - Source PUD-aligned, Destination PUD-aligned
mremap time: 23046ns
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/platforms/Kconfig.cputype | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 3ce907523b1e..2e666e569fdf 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -97,6 +97,8 @@ config PPC_BOOK3S_64
select PPC_HAVE_PMU_SUPPORT
select SYS_SUPPORTS_HUGETLBFS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
+ select HAVE_MOVE_PMD
+ select HAVE_MOVE_PUD
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
select ARCH_SUPPORTS_NUMA_BALANCING
select IRQ_WORK
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] init: consolidate trap_init()
From: Christophe Leroy @ 2021-04-14 9:10 UTC (permalink / raw)
To: Jisheng Zhang, Vineet Gupta, Russell King, Yoshinori Sato,
Brian Cain, Nick Hu, Greentime Hu, Vincent Chen, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Jeff Dike, Richard Weinberger,
Anton Ivanov
Cc: uclinux-h8-devel, linux-parisc, linux-hexagon, linux-um,
linux-kernel, openrisc, Anup Patel, linux-riscv, linux-snps-arc,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210414165808.458a3d11@xhacker.debian>
Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :
> Many architectures implement the trap_init() as NOP, since there is
> no such default for trap_init(), this empty stub is duplicated among
> these architectures. Provide a generic but weak NOP implementation
> to drop the empty stubs of trap_init() in these architectures.
You define the weak function in the __init section.
Most but not all architectures had it in __init section.
And the remaining ones may not be defined in __init section. For instance look at the one in alpha
architecture.
Have you checked that it is not a problem ? It would be good to say something about it in the commit
description.
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> arch/arc/kernel/traps.c | 5 -----
> arch/arm/kernel/traps.c | 5 -----
> arch/h8300/kernel/traps.c | 13 -------------
> arch/hexagon/kernel/traps.c | 4 ----
> arch/nds32/kernel/traps.c | 5 -----
> arch/nios2/kernel/traps.c | 5 -----
> arch/openrisc/kernel/traps.c | 5 -----
> arch/parisc/kernel/traps.c | 4 ----
> arch/powerpc/kernel/traps.c | 5 -----
> arch/riscv/kernel/traps.c | 5 -----
> arch/um/kernel/trap.c | 4 ----
> init/main.c | 2 ++
> 12 files changed, 2 insertions(+), 60 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 53b278845b88..4bdbe2928530 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
> }
> #endif
>
> +void __init __weak trap_init(void) { }
> +
I think in a C file we don't try to save space as much as in a header file.
I would prefer something like:
void __init __weak trap_init(void)
{
}
> /* Report memory auto-initialization states for this boot. */
> static void __init report_meminit(void)
> {
>
^ permalink raw reply
* Re: [PATCH v3] powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall
From: Vaibhav Jain @ 2021-04-14 9:21 UTC (permalink / raw)
To: Aneesh Kumar K.V, Shivaprasad G Bhat, sbhat, linuxppc-dev,
kvm-ppc, linux-nvdimm, ellerman
Cc: linux-doc
In-Reply-To: <877dl530id.fsf@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>
>> Hi Shiva,
>>
>> Apologies for a late review but something just caught my eye while
>> working on a different patch.
>>
>> Shivaprasad G Bhat <sbhat@linux.ibm.com> writes:
>>
>>> Add support for ND_REGION_ASYNC capability if the device tree
>>> indicates 'ibm,hcall-flush-required' property in the NVDIMM node.
>>> Flush is done by issuing H_SCM_FLUSH hcall to the hypervisor.
>>>
>>> If the flush request failed, the hypervisor is expected to
>>> to reflect the problem in the subsequent nvdimm H_SCM_HEALTH call.
>>>
>>> This patch prevents mmap of namespaces with MAP_SYNC flag if the
>>> nvdimm requires an explicit flush[1].
>>>
>>> References:
>>> [1] https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c
>>>
>>> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
>>> ---
>>> v2 - https://www.spinics.net/lists/kvm-ppc/msg18799.html
>>> Changes from v2:
>>> - Fixed the commit message.
>>> - Add dev_dbg before the H_SCM_FLUSH hcall
>>>
>>> v1 - https://www.spinics.net/lists/kvm-ppc/msg18272.html
>>> Changes from v1:
>>> - Hcall semantics finalized, all changes are to accomodate them.
>>>
>>> Documentation/powerpc/papr_hcalls.rst | 14 ++++++++++
>>> arch/powerpc/include/asm/hvcall.h | 3 +-
>>> arch/powerpc/platforms/pseries/papr_scm.c | 40 +++++++++++++++++++++++++++++
>>> 3 files changed, 56 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
>>> index 48fcf1255a33..648f278eea8f 100644
>>> --- a/Documentation/powerpc/papr_hcalls.rst
>>> +++ b/Documentation/powerpc/papr_hcalls.rst
>>> @@ -275,6 +275,20 @@ Health Bitmap Flags:
>>> Given a DRC Index collect the performance statistics for NVDIMM and copy them
>>> to the resultBuffer.
>>>
>>> +**H_SCM_FLUSH**
>>> +
>>> +| Input: *drcIndex, continue-token*
>>> +| Out: *continue-token*
>>> +| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
>>> +
>>> +Given a DRC Index Flush the data to backend NVDIMM device.
>>> +
>>> +The hcall returns H_BUSY when the flush takes longer time and the hcall needs
>>> +to be issued multiple times in order to be completely serviced. The
>>> +*continue-token* from the output to be passed in the argument list of
>>> +subsequent hcalls to the hypervisor until the hcall is completely serviced
>>> +at which point H_SUCCESS or other error is returned by the hypervisor.
>>> +
>> Does the hcall semantic also include measures to trigger a barrier/fence
>> (like pm_wmb()) so that all the stores before the hcall are gauranteed
>> to have hit the pmem controller ?
>
> It is upto the hypervisor to implement the right sequence to ensure the
> guarantee. The hcall doesn't expect the store to reach the platform
> buffers.
Since the asyc_flush function is also called for performing
deep_flush from libnvdimm and as the hcall doesnt gaurantee stores to
reach the platform buffers, hence papr_scm_pmem_flush() should issue
pm_wmb() before the hcall.
This would ensure papr_scm_pmem_flush() semantics are consistent that to
generic_nvdimm_flush().
Also, adding the statement "The hcall doesn't expect the store to reach
the platform buffers" to the hcall documentation would be good to have.
>
>
>>
>> If not then the papr_scm_pmem_flush() introduced below should issue a
>> fence like pm_wmb() before issuing the flush hcall.
>>
>> If yes then this behaviour should also be documented with the hcall
>> semantics above.
>>
>
> IIUC fdatasync on the backend file is enough to ensure the
> guaraantee. Such a request will have REQ_PREFLUSH and REQ_FUA which will
> do the necessary barrier on the backing device holding the backend file.
>
Right, but thats assuming nvdimm is backed by a regular file in
hypervisor which may not always be the case.
> -aneesh
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH] init: consolidate trap_init()
From: Jisheng Zhang @ 2021-04-14 9:27 UTC (permalink / raw)
To: Christophe Leroy
Cc: Anup Patel, James E.J. Bottomley, Paul Mackerras, linux-hexagon,
linux-riscv, Vincent Chen, Anton Ivanov, Jonas Bonn, Brian Cain,
Richard Weinberger, Helge Deller, Russell King, Ley Foon Tan,
linux-parisc, linux-snps-arc, uclinux-h8-devel, Albert Ou,
Jeff Dike, linux-um, Stefan Kristiansson, openrisc, Greentime Hu,
Paul Walmsley, Stafford Horne, linux-arm-kernel, Yoshinori Sato,
Nick Hu, Vineet Gupta, linux-kernel, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <44bdf1f1-117d-0f10-fc59-9edd32d1ad61@csgroup.eu>
On Wed, 14 Apr 2021 11:10:42 +0200
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
> Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :
> > Many architectures implement the trap_init() as NOP, since there is
> > no such default for trap_init(), this empty stub is duplicated among
> > these architectures. Provide a generic but weak NOP implementation
> > to drop the empty stubs of trap_init() in these architectures.
>
> You define the weak function in the __init section.
>
> Most but not all architectures had it in __init section.
>
> And the remaining ones may not be defined in __init section. For instance look at the one in alpha
> architecture.
>
> Have you checked that it is not a problem ? It would be good to say something about it in the commit
> description.
For those non-nop platforms, I can only test x86/arm64/, but both has
__init mark. I'm not sure whether this is a problem for alpha etc. Maybe
I can check which section the trap_init() sits. Or to avoid any possible
regression, I can add __init mark to those remaining ones without it in
preparation patches.
>
>
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > arch/arc/kernel/traps.c | 5 -----
> > arch/arm/kernel/traps.c | 5 -----
> > arch/h8300/kernel/traps.c | 13 -------------
> > arch/hexagon/kernel/traps.c | 4 ----
> > arch/nds32/kernel/traps.c | 5 -----
> > arch/nios2/kernel/traps.c | 5 -----
> > arch/openrisc/kernel/traps.c | 5 -----
> > arch/parisc/kernel/traps.c | 4 ----
> > arch/powerpc/kernel/traps.c | 5 -----
> > arch/riscv/kernel/traps.c | 5 -----
> > arch/um/kernel/trap.c | 4 ----
> > init/main.c | 2 ++
> > 12 files changed, 2 insertions(+), 60 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 53b278845b88..4bdbe2928530 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
> > }
> > #endif
> >
> > +void __init __weak trap_init(void) { }
> > +
>
> I think in a C file we don't try to save space as much as in a header file.
>
This is to follow most weak NOP implementations in init/main.c to make
the style unified in the same file. I'm not sure which is better.
> I would prefer something like:
>
>
> void __init __weak trap_init(void)
> {
> }
>
>
> > /* Report memory auto-initialization states for this boot. */
> > static void __init report_meminit(void)
> > {
> >
^ permalink raw reply
* Re: [PATCH] init: consolidate trap_init()
From: Jisheng Zhang @ 2021-04-14 9:38 UTC (permalink / raw)
To: Christophe Leroy
Cc: Anup Patel, James E.J. Bottomley, Paul Mackerras, linux-hexagon,
linux-riscv, Vincent Chen, Anton Ivanov, Jonas Bonn, Brian Cain,
Richard Weinberger, Helge Deller, Russell King, Ley Foon Tan,
linux-parisc, linux-snps-arc, uclinux-h8-devel, Albert Ou,
Jeff Dike, linux-um, Stefan Kristiansson, openrisc, Greentime Hu,
Paul Walmsley, Stafford Horne, linux-arm-kernel, Yoshinori Sato,
Nick Hu, Vineet Gupta, linux-kernel, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <20210414172757.3ebfaa4c@xhacker.debian>
On Wed, 14 Apr 2021 17:27:57 +0800
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Wed, 14 Apr 2021 11:10:42 +0200
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
> >
> > Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :
> > > Many architectures implement the trap_init() as NOP, since there is
> > > no such default for trap_init(), this empty stub is duplicated among
> > > these architectures. Provide a generic but weak NOP implementation
> > > to drop the empty stubs of trap_init() in these architectures.
> >
> > You define the weak function in the __init section.
> >
> > Most but not all architectures had it in __init section.
> >
> > And the remaining ones may not be defined in __init section. For instance look at the one in alpha
> > architecture.
> >
> > Have you checked that it is not a problem ? It would be good to say something about it in the commit
> > description.
>
> For those non-nop platforms, I can only test x86/arm64/, but both has
> __init mark. I'm not sure whether this is a problem for alpha etc. Maybe
> I can check which section the trap_init() sits. Or to avoid any possible
> regression, I can add __init mark to those remaining ones without it in
> preparation patches.
>
Hi,
I found only three platforms don't have the __init marker for trap_init(), I
will add the __init marker in three preparation patches in new version.
thanks
^ permalink raw reply
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