* Re: [PATCH v2] selftests: powerpc: Fix online CPU selection
From: Sandipan Das @ 2020-07-30 4:59 UTC (permalink / raw)
To: Srikar Dronamraju, mpe; +Cc: shiganta, nasastry, harish, linuxppc-dev, kamalesh
In-Reply-To: <20200729160344.GB14603@linux.vnet.ibm.com>
Hi Srikar, Michael,
On 29/07/20 9:33 pm, Srikar Dronamraju wrote:
> * Sandipan Das <sandipan@linux.ibm.com> [2020-06-09 13:07:33]:
>
>> The size of the CPU affinity mask must be large enough for
>> systems with a very large number of CPUs. Otherwise, tests
>> which try to determine the first online CPU by calling
>> sched_getaffinity() will fail. This makes sure that the size
>> of the allocated affinity mask is dependent on the number of
>> CPUs as reported by get_nprocs().
>>
>> Fixes: 3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
>> Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
>> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
>> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
>> ---
>> Previous versions can be found at:
>> v1: https://lore.kernel.org/linuxppc-dev/20200608144212.985144-1-sandipan@linux.ibm.com/
>>
>> @@ -88,28 +89,40 @@ void *get_auxv_entry(int type)
>>
>> int pick_online_cpu(void)
>> {
>> - cpu_set_t mask;
>> - int cpu;
>> + int ncpus, cpu = -1;
>> + cpu_set_t *mask;
>> + size_t size;
>> +
>> + ncpus = get_nprocs();
>
> Please use get_nprocs_conf or sysconf(_SC_NPROCESSORS_CONF). The manpage
> seems to suggest the latter. Not sure how accurate the manpage is.
>
> get_nprocs is returning online cpus and when smt is off, the cpu numbers
> would be sparse and hence the result from get_nprocs wouldn't be ideal for
> allocating cpumask. However get_nprocs_conf would return the max configured
> cpus and would be able to handle it.
>
> I think this was the same situation hit by Michael Ellerman.
>
Yes, that seems to be the case. Thanks for testing this.
Will fix this in v3.
- Sandipan
^ permalink raw reply
* Re: [PATCH 11/15] memblock: reduce number of parameters in for_each_mem_range()
From: Baoquan He @ 2020-07-30 2:22 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-sh, Peter Zijlstra, Dave Hansen, linux-mips, Max Filippov,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Stafford Horne, Marek Szyprowski, linux-s390, linux-c6x-dev,
Yoshinori Sato, x86, Russell King, Mike Rapoport,
clang-built-linux, Ingo Molnar, Catalin Marinas, uclinux-h8-devel,
linux-xtensa, openrisc, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Michal Simek,
linux-mm, linuxppc-dev, linux-kernel, iommu, Palmer Dabbelt,
Andrew Morton, Christoph Hellwig
In-Reply-To: <20200728051153.1590-12-rppt@kernel.org>
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Currently for_each_mem_range() iterator is the most generic way to traverse
> memblock regions. As such, it has 8 parameters and it is hardly convenient
> to users. Most users choose to utilize one of its wrappers and the only
> user that actually needs most of the parameters outside memblock is s390
> crash dump implementation.
>
> To avoid yet another naming for memblock iterators, rename the existing
> for_each_mem_range() to __for_each_mem_range() and add a new
> for_each_mem_range() wrapper with only index, start and end parameters.
>
> The new wrapper nicely fits into init_unavailable_mem() and will be used in
> upcoming changes to simplify memblock traversals.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> .clang-format | 1 +
> arch/arm64/kernel/machine_kexec_file.c | 6 ++----
> arch/s390/kernel/crash_dump.c | 8 ++++----
> include/linux/memblock.h | 18 ++++++++++++++----
> mm/page_alloc.c | 3 +--
> 5 files changed, 22 insertions(+), 14 deletions(-)
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/.clang-format b/.clang-format
> index a0a96088c74f..52ededab25ce 100644
> --- a/.clang-format
> +++ b/.clang-format
> @@ -205,6 +205,7 @@ ForEachMacros:
> - 'for_each_memblock_type'
> - 'for_each_memcg_cache_index'
> - 'for_each_mem_pfn_range'
> + - '__for_each_mem_range'
> - 'for_each_mem_range'
> - 'for_each_mem_range_rev'
> - 'for_each_migratetype_order'
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 361a1143e09e..5b0e67b93cdc 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -215,8 +215,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> phys_addr_t start, end;
>
> nr_ranges = 1; /* for exclusion of crashkernel region */
> - for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
> - MEMBLOCK_NONE, &start, &end, NULL)
> + for_each_mem_range(i, &start, &end)
> nr_ranges++;
>
> cmem = kmalloc(struct_size(cmem, ranges, nr_ranges), GFP_KERNEL);
> @@ -225,8 +224,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>
> cmem->max_nr_ranges = nr_ranges;
> cmem->nr_ranges = 0;
> - for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
> - MEMBLOCK_NONE, &start, &end, NULL) {
> + for_each_mem_range(i, &start, &end) {
> cmem->ranges[cmem->nr_ranges].start = start;
> cmem->ranges[cmem->nr_ranges].end = end - 1;
> cmem->nr_ranges++;
> diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c
> index f96a5857bbfd..e28085c725ff 100644
> --- a/arch/s390/kernel/crash_dump.c
> +++ b/arch/s390/kernel/crash_dump.c
> @@ -549,8 +549,8 @@ static int get_mem_chunk_cnt(void)
> int cnt = 0;
> u64 idx;
>
> - for_each_mem_range(idx, &memblock.physmem, &oldmem_type, NUMA_NO_NODE,
> - MEMBLOCK_NONE, NULL, NULL, NULL)
> + __for_each_mem_range(idx, &memblock.physmem, &oldmem_type, NUMA_NO_NODE,
> + MEMBLOCK_NONE, NULL, NULL, NULL)
> cnt++;
> return cnt;
> }
> @@ -563,8 +563,8 @@ static void loads_init(Elf64_Phdr *phdr, u64 loads_offset)
> phys_addr_t start, end;
> u64 idx;
>
> - for_each_mem_range(idx, &memblock.physmem, &oldmem_type, NUMA_NO_NODE,
> - MEMBLOCK_NONE, &start, &end, NULL) {
> + __for_each_mem_range(idx, &memblock.physmem, &oldmem_type, NUMA_NO_NODE,
> + MEMBLOCK_NONE, &start, &end, NULL) {
> phdr->p_filesz = end - start;
> phdr->p_type = PT_LOAD;
> phdr->p_offset = start;
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index e6a23b3db696..d70c2835e913 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -142,7 +142,7 @@ void __next_reserved_mem_region(u64 *idx, phys_addr_t *out_start,
> void __memblock_free_late(phys_addr_t base, phys_addr_t size);
>
> /**
> - * for_each_mem_range - iterate through memblock areas from type_a and not
> + * __for_each_mem_range - iterate through memblock areas from type_a and not
> * included in type_b. Or just type_a if type_b is NULL.
> * @i: u64 used as loop variable
> * @type_a: ptr to memblock_type to iterate
> @@ -153,7 +153,7 @@ void __memblock_free_late(phys_addr_t base, phys_addr_t size);
> * @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
> * @p_nid: ptr to int for nid of the range, can be %NULL
> */
> -#define for_each_mem_range(i, type_a, type_b, nid, flags, \
> +#define __for_each_mem_range(i, type_a, type_b, nid, flags, \
> p_start, p_end, p_nid) \
> for (i = 0, __next_mem_range(&i, nid, flags, type_a, type_b, \
> p_start, p_end, p_nid); \
> @@ -182,6 +182,16 @@ void __memblock_free_late(phys_addr_t base, phys_addr_t size);
> __next_mem_range_rev(&i, nid, flags, type_a, type_b, \
> p_start, p_end, p_nid))
>
> +/**
> + * for_each_mem_range - iterate through memory areas.
> + * @i: u64 used as loop variable
> + * @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
> + * @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
> + */
> +#define for_each_mem_range(i, p_start, p_end) \
> + __for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE, \
> + MEMBLOCK_NONE, p_start, p_end, NULL)
> +
> /**
> * for_each_reserved_mem_region - iterate over all reserved memblock areas
> * @i: u64 used as loop variable
> @@ -287,8 +297,8 @@ int __init deferred_page_init_max_threads(const struct cpumask *node_cpumask);
> * soon as memblock is initialized.
> */
> #define for_each_free_mem_range(i, nid, flags, p_start, p_end, p_nid) \
> - for_each_mem_range(i, &memblock.memory, &memblock.reserved, \
> - nid, flags, p_start, p_end, p_nid)
> + __for_each_mem_range(i, &memblock.memory, &memblock.reserved, \
> + nid, flags, p_start, p_end, p_nid)
>
> /**
> * for_each_free_mem_range_reverse - rev-iterate through free memblock areas
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e028b87ce294..95af111d69d3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6972,8 +6972,7 @@ static void __init init_unavailable_mem(void)
> * Loop through unavailable ranges not covered by memblock.memory.
> */
> pgcnt = 0;
> - for_each_mem_range(i, &memblock.memory, NULL,
> - NUMA_NO_NODE, MEMBLOCK_NONE, &start, &end, NULL) {
> + for_each_mem_range(i, &start, &end) {
> if (next < start)
> pgcnt += init_unavailable_range(PFN_DOWN(next),
> PFN_UP(start));
> --
> 2.26.2
>
>
^ permalink raw reply
* Re: [PATCH 10/15] memblock: make memblock_debug and related functionality private
From: Baoquan He @ 2020-07-30 1:54 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-sh, Peter Zijlstra, Dave Hansen, linux-mips, Max Filippov,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Stafford Horne, Marek Szyprowski, linux-s390, linux-c6x-dev,
Yoshinori Sato, x86, Russell King, Mike Rapoport,
clang-built-linux, Ingo Molnar, Catalin Marinas, uclinux-h8-devel,
linux-xtensa, openrisc, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Michal Simek,
linux-mm, linuxppc-dev, linux-kernel, iommu, Palmer Dabbelt,
Andrew Morton, Christoph Hellwig
In-Reply-To: <20200728051153.1590-11-rppt@kernel.org>
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The only user of memblock_dbg() outside memblock was s390 setup code and it
> is converted to use pr_debug() instead.
> This allows to stop exposing memblock_debug and memblock_dbg() to the rest
> of the kernel.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/s390/kernel/setup.c | 4 ++--
> include/linux/memblock.h | 12 +-----------
> mm/memblock.c | 13 +++++++++++--
> 3 files changed, 14 insertions(+), 15 deletions(-)
Nice clean up.
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 07aa15ba43b3..8b284cf6e199 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -776,8 +776,8 @@ static void __init memblock_add_mem_detect_info(void)
> unsigned long start, end;
> int i;
>
> - memblock_dbg("physmem info source: %s (%hhd)\n",
> - get_mem_info_source(), mem_detect.info_source);
> + pr_debug("physmem info source: %s (%hhd)\n",
> + get_mem_info_source(), mem_detect.info_source);
> /* keep memblock lists close to the kernel */
> memblock_set_bottom_up(true);
> for_each_mem_detect_block(i, &start, &end) {
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 220b5f0dad42..e6a23b3db696 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -90,7 +90,6 @@ struct memblock {
> };
>
> extern struct memblock memblock;
> -extern int memblock_debug;
>
> #ifndef CONFIG_ARCH_KEEP_MEMBLOCK
> #define __init_memblock __meminit
> @@ -102,9 +101,6 @@ void memblock_discard(void);
> static inline void memblock_discard(void) {}
> #endif
>
> -#define memblock_dbg(fmt, ...) \
> - if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> -
> phys_addr_t memblock_find_in_range(phys_addr_t start, phys_addr_t end,
> phys_addr_t size, phys_addr_t align);
> void memblock_allow_resize(void);
> @@ -456,13 +452,7 @@ bool memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> bool memblock_is_reserved(phys_addr_t addr);
> bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
>
> -extern void __memblock_dump_all(void);
> -
> -static inline void memblock_dump_all(void)
> -{
> - if (memblock_debug)
> - __memblock_dump_all();
> -}
> +void memblock_dump_all(void);
>
> /**
> * memblock_set_current_limit - Set the current allocation limit to allow
> diff --git a/mm/memblock.c b/mm/memblock.c
> index a5b9b3df81fc..824938849f6d 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -134,7 +134,10 @@ struct memblock memblock __initdata_memblock = {
> i < memblock_type->cnt; \
> i++, rgn = &memblock_type->regions[i])
>
> -int memblock_debug __initdata_memblock;
> +#define memblock_dbg(fmt, ...) \
> + if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> +
> +static int memblock_debug __initdata_memblock;
> static bool system_has_some_mirror __initdata_memblock = false;
> static int memblock_can_resize __initdata_memblock;
> static int memblock_memory_in_slab __initdata_memblock = 0;
> @@ -1919,7 +1922,7 @@ static void __init_memblock memblock_dump(struct memblock_type *type)
> }
> }
>
> -void __init_memblock __memblock_dump_all(void)
> +static void __init_memblock __memblock_dump_all(void)
> {
> pr_info("MEMBLOCK configuration:\n");
> pr_info(" memory size = %pa reserved size = %pa\n",
> @@ -1933,6 +1936,12 @@ void __init_memblock __memblock_dump_all(void)
> #endif
> }
>
> +void __init_memblock memblock_dump_all(void)
> +{
> + if (memblock_debug)
> + __memblock_dump_all();
> +}
> +
> void __init memblock_allow_resize(void)
> {
> memblock_can_resize = 1;
> --
> 2.26.2
>
>
^ permalink raw reply
* Re: [PATCH 09/15] memblock: make for_each_memblock_type() iterator private
From: Baoquan He @ 2020-07-30 1:52 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-sh, Peter Zijlstra, Dave Hansen, linux-mips, Max Filippov,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Stafford Horne, Marek Szyprowski, linux-s390, linux-c6x-dev,
Yoshinori Sato, x86, Russell King, Mike Rapoport,
clang-built-linux, Ingo Molnar, Catalin Marinas, uclinux-h8-devel,
linux-xtensa, openrisc, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Michal Simek,
linux-mm, linuxppc-dev, linux-kernel, iommu, Palmer Dabbelt,
Andrew Morton, Christoph Hellwig
In-Reply-To: <20200728051153.1590-10-rppt@kernel.org>
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> for_each_memblock_type() is not used outside mm/memblock.c, move it there
> from include/linux/memblock.h
>
> ---
> include/linux/memblock.h | 5 -----
> mm/memblock.c | 5 +++++
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 017fae833d4a..220b5f0dad42 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -532,11 +532,6 @@ static inline unsigned long memblock_region_reserved_end_pfn(const struct memblo
> region < (memblock.memblock_type.regions + memblock.memblock_type.cnt); \
> region++)
>
> -#define for_each_memblock_type(i, memblock_type, rgn) \
> - for (i = 0, rgn = &memblock_type->regions[0]; \
> - i < memblock_type->cnt; \
> - i++, rgn = &memblock_type->regions[i])
> -
> extern void *alloc_large_system_hash(const char *tablename,
> unsigned long bucketsize,
> unsigned long numentries,
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 39aceafc57f6..a5b9b3df81fc 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -129,6 +129,11 @@ struct memblock memblock __initdata_memblock = {
> .current_limit = MEMBLOCK_ALLOC_ANYWHERE,
> };
>
> +#define for_each_memblock_type(i, memblock_type, rgn) \
> + for (i = 0, rgn = &memblock_type->regions[0]; \
> + i < memblock_type->cnt; \
> + i++, rgn = &memblock_type->regions[i])
> +
Reviewed-by: Baoquan He <bhe@redhat.com>
^ permalink raw reply
* Re: [PATCH v2] powerpc/vio: drop bus_type from parent device
From: Michael Ellerman @ 2020-07-30 1:28 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, linuxppc-dev
Cc: cascardo, Peter Rajnoha, gregkh
In-Reply-To: <20200406155748.6761-1-cascardo@canonical.com>
[ Added Peter & Greg to Cc ]
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> writes:
> Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error
> code if writing /sys/.../uevent fails") started returning failure when
> writing to /sys/devices/vio/uevent.
>
> This causes an early udevadm trigger to fail. On some installer versions of
> Ubuntu, this will cause init to exit, thus panicing the system very early
> during boot.
>
> Removing the bus_type from the parent device will remove some of the extra
> empty files from /sys/devices/vio/, but will keep the rest of the layout
> for vio devices, keeping them under /sys/devices/vio/.
What exactly does it change?
I'm finding it hard to evaluate if this change is going to cause a
regression somehow.
I'm also not clear on why removing the bus type is correct, apart from
whether it fixes the bug you're seeing.
> It has been tested that uevents for vio devices don't change after this
> fix, they still contain MODALIAS.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> Fixes: df44b479654f ("kobject: return error code if writing /sys/.../uevent fails")
AFAICS there haven't been any other fixes for that commit. Do we know
why it is only vio that was affected? (possibly because it's a fake bus
to begin with?)
cheers
> diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
> index 37f1f25ba804..a94dab3972a0 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -36,7 +36,6 @@ static struct vio_dev vio_bus_device = { /* fake "parent" device */
> .name = "vio",
> .type = "",
> .dev.init_name = "vio",
> - .dev.bus = &vio_bus_type,
> };
>
> #ifdef CONFIG_PPC_SMLPAR
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Michael Ellerman @ 2020-07-30 0:57 UTC (permalink / raw)
To: Nathan Lynch, Laurent Dufour; +Cc: tyreld, cheloha, linuxppc-dev
In-Reply-To: <878sf31m8k.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> Le 28/07/2020 à 19:37, Nathan Lynch a écrit :
>>> The drmem lmb list can have hundreds of thousands of entries, and
>>> unfortunately lookups take the form of linear searches. As long as
>>> this is the case, traversals have the potential to monopolize the CPU
>>> and provoke lockup reports, workqueue stalls, and the like unless
>>> they explicitly yield.
>>>
>>> Rather than placing cond_resched() calls within various
>>> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
>>> expression of the loop macro itself so users can't omit it.
>>
>> Is that not too much to call cond_resched() on every LMB?
>>
>> Could that be less frequent, every 10, or 100, I don't really know ?
>
> Everything done within for_each_drmem_lmb is relatively heavyweight
> already. E.g. calling dlpar_remove_lmb()/dlpar_add_lmb() can take dozens
> of milliseconds. I don't think cond_resched() is an expensive check in
> this context.
Hmm, mostly.
But there are quite a few cases like drmem_update_dt_v1():
for_each_drmem_lmb(lmb) {
dr_cell->base_addr = cpu_to_be64(lmb->base_addr);
dr_cell->drc_index = cpu_to_be32(lmb->drc_index);
dr_cell->aa_index = cpu_to_be32(lmb->aa_index);
dr_cell->flags = cpu_to_be32(drmem_lmb_flags(lmb));
dr_cell++;
}
Which will compile to a pretty tight loop at the moment.
Or drmem_update_dt_v2() which has two loops over all lmbs.
And although the actual TIF check is cheap the function call to do it is
not free.
So I worry this is going to make some of those long loops take even longer.
At the same time I don't see an easy way to batch the calls to
cond_resched() without more intrusive changes.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
From: Segher Boessenkool @ 2020-07-29 22:44 UTC (permalink / raw)
To: Vladis Dronov
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <584129967.9672326.1596051896801.JavaMail.zimbra@redhat.com>
On Wed, Jul 29, 2020 at 03:44:56PM -0400, Vladis Dronov wrote:
> > > Certain warnings are emitted for powerpc code when building with a gcc-10
> > > toolset:
> > >
> > > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
> > > reference from the function remove_pmd_table() to the function
> > > .meminit.text:split_kernel_mapping()
> > > The function remove_pmd_table() references
> > > the function __meminit split_kernel_mapping().
> > > This is often because remove_pmd_table lacks a __meminit
> > > annotation or the annotation of split_kernel_mapping is wrong.
> > >
> > > Add the appropriate __init and __meminit annotations to make modpost not
> > > complain. In all the cases there are just a single callsite from another
> > > __init or __meminit function:
> > >
> > > __meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
> > > __init prom_init() -> setup_secure_guest()
> > > __init xive_spapr_init() -> xive_spapr_disabled()
> >
> > So what changed? These functions were inlined with older compilers, but
> > not anymore?
>
> Yes, exactly. Gcc-10 does not inline them anymore. If this is because of my
> build system, this can happen to others also.
>
> The same thing was fixed by Linus in e99332e7b4cd ("gcc-10: mark more functions
> __init to avoid section mismatch warnings").
It sounds like this is part of "-finline-functions was retuned" on
<https://gcc.gnu.org/gcc-10/changes.html>? So everyone should see it
(no matter what config or build system), and it is a good thing too :-)
Thanks for the confirmation,
Segher
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path
From: Thomas Falcon @ 2020-07-29 22:37 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: drt, netdev, linuxppc-dev
In-Reply-To: <20200729152820.79c00fe7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 7/29/20 5:28 PM, Jakub Kicinski wrote:
> On Wed, 29 Jul 2020 16:36:32 -0500 Thomas Falcon wrote:
>> RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
>> error paths. Fix this and dispose of TX IRQ mappings correctly in
>> case of an error.
>>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
> Thomas, please remember about Fixes tags (for networking patches,
> at least):
>
> Fixes: ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
Sorry, Jakub, I will try not to forget next time. Thanks.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path
From: David Miller @ 2020-07-29 22:36 UTC (permalink / raw)
To: tlfalcon; +Cc: drt, netdev, linuxppc-dev
In-Reply-To: <1596058592-12025-1-git-send-email-tlfalcon@linux.ibm.com>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Wed, 29 Jul 2020 16:36:32 -0500
> RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
> error paths. Fix this and dispose of TX IRQ mappings correctly in
> case of an error.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Applied with Fixes: tag added and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path
From: Jakub Kicinski @ 2020-07-29 22:28 UTC (permalink / raw)
To: Thomas Falcon; +Cc: drt, netdev, linuxppc-dev
In-Reply-To: <1596058592-12025-1-git-send-email-tlfalcon@linux.ibm.com>
On Wed, 29 Jul 2020 16:36:32 -0500 Thomas Falcon wrote:
> RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
> error paths. Fix this and dispose of TX IRQ mappings correctly in
> case of an error.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Thomas, please remember about Fixes tags (for networking patches,
at least):
Fixes: ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
^ permalink raw reply
* Re: [PATCH v2] pseries/drmem: don't cache node id in drmem_lmb struct
From: Laurent Dufour @ 2020-07-29 15:32 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Michal Suchanek, David Hildenbrand, Rick Lindsley
In-Reply-To: <20200728165339.3031126-1-cheloha@linux.ibm.com>
Hi Scott,
Le 28/07/2020 à 18:53, Scott Cheloha a écrit :
> At memory hot-remove time we can retrieve an LMB's nid from its
> corresponding memory_block. There is no need to store the nid
> in multiple locations.
>
> Note that lmb_to_memblock() uses find_memory_block() to get the
> corresponding memory_block. As find_memory_block() runs in sub-linear
> time this approach is negligibly slower than what we do at present.
>
> In exchange for this lookup at hot-remove time we no longer need to
> call memory_add_physaddr_to_nid() during drmem_init() for each LMB.
> On powerpc, memory_add_physaddr_to_nid() is a linear search, so this
> spares us an O(n^2) initialization during boot.
>
> On systems with many LMBs that initialization overhead is palpable and
> disruptive. For example, on a box with 249854 LMBs we're seeing
> drmem_init() take upwards of 30 seconds to complete:
>
> [ 53.721639] drmem: initializing drmem v2
> [ 80.604346] watchdog: BUG: soft lockup - CPU#65 stuck for 23s! [swapper/0:1]
> [ 80.604377] Modules linked in:
> [ 80.604389] CPU: 65 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc2+ #4
> [ 80.604397] NIP: c0000000000a4980 LR: c0000000000a4940 CTR: 0000000000000000
> [ 80.604407] REGS: c0002dbff8493830 TRAP: 0901 Not tainted (5.6.0-rc2+)
> [ 80.604412] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 44000248 XER: 0000000d
> [ 80.604431] CFAR: c0000000000a4a38 IRQMASK: 0
> [ 80.604431] GPR00: c0000000000a4940 c0002dbff8493ac0 c000000001904400 c0003cfffffede30
> [ 80.604431] GPR04: 0000000000000000 c000000000f4095a 000000000000002f 0000000010000000
> [ 80.604431] GPR08: c0000bf7ecdb7fb8 c0000bf7ecc2d3c8 0000000000000008 c00c0002fdfb2001
> [ 80.604431] GPR12: 0000000000000000 c00000001e8ec200
> [ 80.604477] NIP [c0000000000a4980] hot_add_scn_to_nid+0xa0/0x3e0
> [ 80.604486] LR [c0000000000a4940] hot_add_scn_to_nid+0x60/0x3e0
> [ 80.604492] Call Trace:
> [ 80.604498] [c0002dbff8493ac0] [c0000000000a4940] hot_add_scn_to_nid+0x60/0x3e0 (unreliable)
> [ 80.604509] [c0002dbff8493b20] [c000000000087c10] memory_add_physaddr_to_nid+0x20/0x60
> [ 80.604521] [c0002dbff8493b40] [c0000000010d4880] drmem_init+0x25c/0x2f0
> [ 80.604530] [c0002dbff8493c10] [c000000000010154] do_one_initcall+0x64/0x2c0
> [ 80.604540] [c0002dbff8493ce0] [c0000000010c4aa0] kernel_init_freeable+0x2d8/0x3a0
> [ 80.604550] [c0002dbff8493db0] [c000000000010824] kernel_init+0x2c/0x148
> [ 80.604560] [c0002dbff8493e20] [c00000000000b648] ret_from_kernel_thread+0x5c/0x74
> [ 80.604567] Instruction dump:
> [ 80.604574] 392918e8 e9490000 e90a000a e92a0000 80ea000c 1d080018 3908ffe8 7d094214
> [ 80.604586] 7fa94040 419d00dc e9490010 714a0088 <2faa0008> 409e00ac e9490000 7fbe5040
> [ 89.047390] drmem: 249854 LMB(s)
>
> With a patched kernel on the same machine we're no longer seeing the
> soft lockup. drmem_init() now completes in negligible time, even when
> the LMB count is large.
>
> Signed-off-by: Scott Cheloha <cheloha@linux.ibm.com>
> ---
> arch/powerpc/include/asm/drmem.h | 21 -------------------
> arch/powerpc/mm/drmem.c | 6 +-----
> .../platforms/pseries/hotplug-memory.c | 19 ++++++++++-------
> 3 files changed, 13 insertions(+), 33 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
> index 414d209f45bb..34e4e9b257f5 100644
> --- a/arch/powerpc/include/asm/drmem.h
> +++ b/arch/powerpc/include/asm/drmem.h
> @@ -13,9 +13,6 @@ struct drmem_lmb {
> u32 drc_index;
> u32 aa_index;
> u32 flags;
> -#ifdef CONFIG_MEMORY_HOTPLUG
> - int nid;
> -#endif
> };
>
> struct drmem_lmb_info {
> @@ -104,22 +101,4 @@ static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
> lmb->aa_index = 0xffffffff;
> }
>
> -#ifdef CONFIG_MEMORY_HOTPLUG
> -static inline void lmb_set_nid(struct drmem_lmb *lmb)
> -{
> - lmb->nid = memory_add_physaddr_to_nid(lmb->base_addr);
> -}
> -static inline void lmb_clear_nid(struct drmem_lmb *lmb)
> -{
> - lmb->nid = -1;
> -}
> -#else
> -static inline void lmb_set_nid(struct drmem_lmb *lmb)
> -{
> -}
> -static inline void lmb_clear_nid(struct drmem_lmb *lmb)
> -{
> -}
> -#endif
> -
> #endif /* _ASM_POWERPC_LMB_H */
> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
> index 59327cefbc6a..873fcfc7b875 100644
> --- a/arch/powerpc/mm/drmem.c
> +++ b/arch/powerpc/mm/drmem.c
> @@ -362,10 +362,8 @@ static void __init init_drmem_v1_lmbs(const __be32 *prop)
> if (!drmem_info->lmbs)
> return;
>
> - for_each_drmem_lmb(lmb) {
> + for_each_drmem_lmb(lmb)
> read_drconf_v1_cell(lmb, &prop);
> - lmb_set_nid(lmb);
> - }
> }
>
> static void __init init_drmem_v2_lmbs(const __be32 *prop)
> @@ -410,8 +408,6 @@ static void __init init_drmem_v2_lmbs(const __be32 *prop)
>
> lmb->aa_index = dr_cell.aa_index;
> lmb->flags = dr_cell.flags;
> -
> - lmb_set_nid(lmb);
> }
> }
> }
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 5ace2f9a277e..7bf66fdcf916 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -356,25 +356,29 @@ static int dlpar_add_lmb(struct drmem_lmb *);
>
> static int dlpar_remove_lmb(struct drmem_lmb *lmb)
> {
> + struct memory_block *mem_block;
> unsigned long block_sz;
> int rc;
>
> if (!lmb_is_removable(lmb))
> return -EINVAL;
>
> + mem_block = lmb_to_memblock(lmb);
> + if (mem_block == NULL)
> + return -EINVAL;
> +
lmb_to_memblock is 'getting' the memblock's device, so you should call
put_device(mem_block->device) to reverse that operation.
Something like:
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -367,7 +367,7 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
rc = dlpar_offline_lmb(lmb);
if (rc)
- return rc;
+ goto out;
block_sz = pseries_memory_block_size();
@@ -379,7 +379,9 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
invalidate_lmb_associativity_index(lmb);
lmb->flags &= ~DRCONF_MEM_ASSIGNED;
- return 0;
+out:
+ put_device(&mem_block->dev);
+ return rc;
}
static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
> rc = dlpar_offline_lmb(lmb);
> if (rc)
> return rc;
>
> block_sz = pseries_memory_block_size();
>
> - __remove_memory(lmb->nid, lmb->base_addr, block_sz);
> + __remove_memory(mem_block->nid, lmb->base_addr, block_sz);
>
> /* Update memory regions for memory remove */
> memblock_remove(lmb->base_addr, block_sz);
>
> invalidate_lmb_associativity_index(lmb);
> - lmb_clear_nid(lmb);
> lmb->flags &= ~DRCONF_MEM_ASSIGNED;
>
> return 0;
> @@ -631,7 +635,7 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> static int dlpar_add_lmb(struct drmem_lmb *lmb)
> {
> unsigned long block_sz;
> - int rc;
> + int nid, rc;
>
> if (lmb->flags & DRCONF_MEM_ASSIGNED)
> return -EINVAL;
> @@ -642,11 +646,13 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
> return rc;
> }
>
> - lmb_set_nid(lmb);
> block_sz = memory_block_size_bytes();
>
> + /* Find the node id for this address. */
> + nid = memory_add_physaddr_to_nid(lmb->base_addr);
This function is calling hot_add_drconf_scn_to_nid() which is walking all the
LMBs linearly, so we may spend a lot of time here.
I think it be nice to take some breath in the caller's loop in
dlpar_memory_add_by_count() to avoid soft lockup to be raised there when adding
a large number of LMBs, isn't it?
Nathan sent a patch to add such a breath in for_each_drmem_lmb_in_range() may be
it would be nice to add one in dlpar_memory_add_by_count() through that patch.
> +
> /* Add the memory */
> - rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
> + rc = __add_memory(nid, lmb->base_addr, block_sz);
> if (rc) {
> invalidate_lmb_associativity_index(lmb);
> return rc;
> @@ -654,9 +660,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
>
> rc = dlpar_online_lmb(lmb);
> if (rc) {
> - __remove_memory(lmb->nid, lmb->base_addr, block_sz);
> + __remove_memory(nid, lmb->base_addr, block_sz);
> invalidate_lmb_associativity_index(lmb);
> - lmb_clear_nid(lmb);
> } else {
> lmb->flags |= DRCONF_MEM_ASSIGNED;
> }
>
^ permalink raw reply
* linux-next: Fixes tag needs some work in the powerpc tree
From: Stephen Rothwell @ 2020-07-29 21:55 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Athira Rajeev, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi all,
In commit
443359aebce0 ("powerpc/perf: Fix MMCRA_BHRB_DISABLE define for binutils < 2.28")
Fixes tag
Fixes: 9908c826d5ed ("Add Power10 PMU feature to DT CPU features")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
Just a hint for the future.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 2/2] spi: mpc512x-psc: Convert to use GPIO descriptors
From: Linus Walleij @ 2020-07-29 21:48 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: Linus Walleij, Anatolij Gustschin, linuxppc-dev,
Uwe Kleine-König
In-Reply-To: <20200729214817.478834-1-linus.walleij@linaro.org>
This driver is already relying on the core to provide
valid GPIO numbers in spi->cs_gpio through
of_spi_get_gpio_numbers(), so we can switch to letting
the core use GPIO descriptors instead.
Make sure that the .set_cs() is always called, as some controller
set-up is also needed.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/spi/spi-mpc512x-psc.c | 33 +++++++--------------------------
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 35313a77f977..dd8bba408301 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -23,7 +23,6 @@
#include <linux/clk.h>
#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
-#include <linux/gpio.h>
#include <asm/mpc52xx_psc.h>
enum {
@@ -99,7 +98,7 @@ static void mpc512x_psc_spi_set_cs(struct spi_device *spi, bool enable)
u16 bclkdiv;
if (!enable) {
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ if (mps->cs_control && spi->cs_gpiod)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
return;
}
@@ -134,7 +133,7 @@ static void mpc512x_psc_spi_set_cs(struct spi_device *spi, bool enable)
out_be32(psc_addr(mps, ccr), ccr);
mps->bits_per_word = cs->bits_per_word;
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ if (mps->cs_control && spi->cs_gpiod)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
}
@@ -358,18 +357,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
if (!cs)
return -ENOMEM;
- if (gpio_is_valid(spi->cs_gpio)) {
- ret = gpio_request(spi->cs_gpio, dev_name(&spi->dev));
- if (ret) {
- dev_err(&spi->dev, "can't get CS gpio: %d\n",
- ret);
- kfree(cs);
- return ret;
- }
- gpio_direction_output(spi->cs_gpio,
- spi->mode & SPI_CS_HIGH ? 0 : 1);
- }
-
spi->controller_state = cs;
}
@@ -381,8 +368,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
static void mpc512x_psc_spi_cleanup(struct spi_device *spi)
{
- if (gpio_is_valid(spi->cs_gpio))
- gpio_free(spi->cs_gpio);
kfree(spi->controller_state);
}
@@ -461,11 +446,6 @@ static irqreturn_t mpc512x_psc_spi_isr(int irq, void *dev_id)
return IRQ_NONE;
}
-static void mpc512x_spi_cs_control(struct spi_device *spi, bool onoff)
-{
- gpio_set_value(spi->cs_gpio, onoff);
-}
-
static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
u32 size, unsigned int irq)
{
@@ -485,10 +465,8 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
mps->type = (int)of_device_get_match_data(dev);
mps->irq = irq;
- if (pdata == NULL) {
- mps->cs_control = mpc512x_spi_cs_control;
- } else {
- mps->cs_control = pdata->cs_control;
+ if (pdata) {
+ mps->cs_control = pdata->cs_control;x
master->bus_num = pdata->bus_num;
master->num_chipselect = pdata->max_chipselect;
}
@@ -499,6 +477,9 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
master->transfer_one_message = mpc512x_psc_spi_msg_xfer;
master->unprepare_transfer_hardware = mpc512x_psc_spi_unprep_xfer_hw;
master->set_cs = mpc512x_psc_spi_set_cs;
+ /* This makes sure our custom .set_cs() is always called */
+ master->flags = SPI_MASTER_GPIO_SS;
+ master->use_gpio_descriptors = true;
master->cleanup = mpc512x_psc_spi_cleanup;
master->dev.of_node = dev->of_node;
--
2.26.2
^ permalink raw reply related
* [PATCH 1/2] spi: mpc512x-psc: Use the framework .set_cs()
From: Linus Walleij @ 2020-07-29 21:48 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: Linus Walleij, Anatolij Gustschin, linuxppc-dev,
Uwe Kleine-König
The mpc512x-psc is rolling its own chip select control code,
but the SPI master framework can handle this. It was also
evaluating the CS status for each transfer but the CS change
should be per-message not per-transfer.
Switch to use the core .set_cs() to control the chip select.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/spi/spi-mpc512x-psc.c | 30 ++++++++----------------------
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index ea1b07953d38..35313a77f977 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -89,7 +89,7 @@ static int mpc512x_psc_spi_transfer_setup(struct spi_device *spi,
return 0;
}
-static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
+static void mpc512x_psc_spi_set_cs(struct spi_device *spi, bool enable)
{
struct mpc512x_psc_spi_cs *cs = spi->controller_state;
struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
@@ -98,6 +98,12 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
int speed;
u16 bclkdiv;
+ if (!enable) {
+ if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
+ return;
+ }
+
sicr = in_be32(psc_addr(mps, sicr));
/* Set clock phase and polarity */
@@ -132,15 +138,6 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
}
-static void mpc512x_psc_spi_deactivate_cs(struct spi_device *spi)
-{
- struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
-
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
- mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
-
-}
-
/* extract and scale size field in txsz or rxsz */
#define MPC512x_PSC_FIFO_SZ(sz) ((sz & 0x7ff) << 2);
@@ -290,40 +287,28 @@ static int mpc512x_psc_spi_msg_xfer(struct spi_master *master,
struct spi_message *m)
{
struct spi_device *spi;
- unsigned cs_change;
int status;
struct spi_transfer *t;
spi = m->spi;
- cs_change = 1;
status = 0;
list_for_each_entry(t, &m->transfers, transfer_list) {
status = mpc512x_psc_spi_transfer_setup(spi, t);
if (status < 0)
break;
- if (cs_change)
- mpc512x_psc_spi_activate_cs(spi);
- cs_change = t->cs_change;
-
status = mpc512x_psc_spi_transfer_rxtx(spi, t);
if (status)
break;
m->actual_length += t->len;
spi_transfer_delay_exec(t);
-
- if (cs_change)
- mpc512x_psc_spi_deactivate_cs(spi);
}
m->status = status;
if (m->complete)
m->complete(m->context);
- if (status || !cs_change)
- mpc512x_psc_spi_deactivate_cs(spi);
-
mpc512x_psc_spi_transfer_setup(spi, NULL);
spi_finalize_current_message(master);
@@ -513,6 +498,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
master->prepare_transfer_hardware = mpc512x_psc_spi_prep_xfer_hw;
master->transfer_one_message = mpc512x_psc_spi_msg_xfer;
master->unprepare_transfer_hardware = mpc512x_psc_spi_unprep_xfer_hw;
+ master->set_cs = mpc512x_psc_spi_set_cs;
master->cleanup = mpc512x_psc_spi_cleanup;
master->dev.of_node = dev->of_node;
--
2.26.2
^ permalink raw reply related
* [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path
From: Thomas Falcon @ 2020-07-29 21:36 UTC (permalink / raw)
To: netdev; +Cc: drt, Thomas Falcon, linuxppc-dev
RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
error paths. Fix this and dispose of TX IRQ mappings correctly in
case of an error.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 0fd7eae..5afb3c9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3206,7 +3206,7 @@ static int init_sub_crq_irqs(struct ibmvnic_adapter *adapter)
req_tx_irq_failed:
for (j = 0; j < i; j++) {
free_irq(adapter->tx_scrq[j]->irq, adapter->tx_scrq[j]);
- irq_dispose_mapping(adapter->rx_scrq[j]->irq);
+ irq_dispose_mapping(adapter->tx_scrq[j]->irq);
}
release_sub_crqs(adapter, 1);
return rc;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
From: Vladis Dronov @ 2020-07-29 19:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <20200729144949.GF17447@gate.crashing.org>
Hello,
----- Original Message -----
> From: "Segher Boessenkool" <segher@kernel.crashing.org>
> To: "Vladis Dronov" <vdronov@redhat.com>
> Cc: linuxppc-dev@lists.ozlabs.org, "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>, linux-kernel@vger.kernel.org,
> "Paul Mackerras" <paulus@samba.org>
> Sent: Wednesday, July 29, 2020 4:49:49 PM
> Subject: Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
>
> On Wed, Jul 29, 2020 at 03:37:41PM +0200, Vladis Dronov wrote:
> > Certain warnings are emitted for powerpc code when building with a gcc-10
> > toolset:
> >
> > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
> > reference from the function remove_pmd_table() to the function
> > .meminit.text:split_kernel_mapping()
> > The function remove_pmd_table() references
> > the function __meminit split_kernel_mapping().
> > This is often because remove_pmd_table lacks a __meminit
> > annotation or the annotation of split_kernel_mapping is wrong.
> >
> > Add the appropriate __init and __meminit annotations to make modpost not
> > complain. In all the cases there are just a single callsite from another
> > __init or __meminit function:
> >
> > __meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
> > __init prom_init() -> setup_secure_guest()
> > __init xive_spapr_init() -> xive_spapr_disabled()
>
> So what changed? These functions were inlined with older compilers, but
> not anymore?
Yes, exactly. Gcc-10 does not inline them anymore. If this is because of my
build system, this can happen to others also.
The same thing was fixed by Linus in e99332e7b4cd ("gcc-10: mark more functions
__init to avoid section mismatch warnings").
>
> Segher
Best regards,
Vladis Dronov | Red Hat, Inc. | The Core Kernel | Senior Software Engineer
^ permalink raw reply
* Re: [PATCH v2] selftests: powerpc: Fix online CPU selection
From: Srikar Dronamraju @ 2020-07-29 16:03 UTC (permalink / raw)
To: Sandipan Das; +Cc: kamalesh, shiganta, nasastry, harish, linuxppc-dev
In-Reply-To: <20200609073733.997643-1-sandipan@linux.ibm.com>
* Sandipan Das <sandipan@linux.ibm.com> [2020-06-09 13:07:33]:
> The size of the CPU affinity mask must be large enough for
> systems with a very large number of CPUs. Otherwise, tests
> which try to determine the first online CPU by calling
> sched_getaffinity() will fail. This makes sure that the size
> of the allocated affinity mask is dependent on the number of
> CPUs as reported by get_nprocs().
>
> Fixes: 3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
> Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> ---
> Previous versions can be found at:
> v1: https://lore.kernel.org/linuxppc-dev/20200608144212.985144-1-sandipan@linux.ibm.com/
>
> @@ -88,28 +89,40 @@ void *get_auxv_entry(int type)
>
> int pick_online_cpu(void)
> {
> - cpu_set_t mask;
> - int cpu;
> + int ncpus, cpu = -1;
> + cpu_set_t *mask;
> + size_t size;
> +
> + ncpus = get_nprocs();
Please use get_nprocs_conf or sysconf(_SC_NPROCESSORS_CONF). The manpage
seems to suggest the latter. Not sure how accurate the manpage is.
get_nprocs is returning online cpus and when smt is off, the cpu numbers
would be sparse and hence the result from get_nprocs wouldn't be ideal for
allocating cpumask. However get_nprocs_conf would return the max configured
cpus and would be able to handle it.
I think this was the same situation hit by Michael Ellerman.
> + size = CPU_ALLOC_SIZE(ncpus);
> + mask = CPU_ALLOC(ncpus);
> + if (!mask) {
> + perror("malloc");
> + return -1;
> + }
>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH] powerpc/fadump: Fix build error with CONFIG_PRESERVE_FA_DUMP=y
From: Gustavo Romero @ 2020-07-29 15:03 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200727070341.595634-1-mpe@ellerman.id.au>
On 7/27/20 4:03 AM, Michael Ellerman wrote:
> skiroot_defconfig fails:
>
> arch/powerpc/kernel/fadump.c:48:17: error: ‘cpus_in_fadump’ defined but not used
> 48 | static atomic_t cpus_in_fadump;
>
> Fix it by moving the definition into the #ifdef where it's used.
>
> Fixes: ba608c4fa12c ("powerpc/fadump: fix race between pstore write and fadump crash trigger")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/kernel/fadump.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 1858896d6809..10ebb4bf71ad 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -45,10 +45,12 @@ static struct fw_dump fw_dump;
> static void __init fadump_reserve_crash_area(u64 base);
>
> struct kobject *fadump_kobj;
> -static atomic_t cpus_in_fadump;
>
> #ifndef CONFIG_PRESERVE_FA_DUMP
> +
> +static atomic_t cpus_in_fadump;
> static DEFINE_MUTEX(fadump_mutex);
> +
> struct fadump_mrange_info crash_mrange_info = { "crash", NULL, 0, 0, 0, false };
>
> #define RESERVED_RNGS_SZ 16384 /* 16K - 128 entries */
>
Tested-by: Gustavo Romero <gromero@linux.ibm.com>
Thanks,
Gustavo
^ permalink raw reply
* Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
From: Segher Boessenkool @ 2020-07-29 14:49 UTC (permalink / raw)
To: Vladis Dronov
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <20200729133741.62789-1-vdronov@redhat.com>
On Wed, Jul 29, 2020 at 03:37:41PM +0200, Vladis Dronov wrote:
> Certain warnings are emitted for powerpc code when building with a gcc-10
> toolset:
>
> WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
> reference from the function remove_pmd_table() to the function
> .meminit.text:split_kernel_mapping()
> The function remove_pmd_table() references
> the function __meminit split_kernel_mapping().
> This is often because remove_pmd_table lacks a __meminit
> annotation or the annotation of split_kernel_mapping is wrong.
>
> Add the appropriate __init and __meminit annotations to make modpost not
> complain. In all the cases there are just a single callsite from another
> __init or __meminit function:
>
> __meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
> __init prom_init() -> setup_secure_guest()
> __init xive_spapr_init() -> xive_spapr_disabled()
So what changed? These functions were inlined with older compilers, but
not anymore?
Segher
^ permalink raw reply
* [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
From: Vladis Dronov @ 2020-07-29 13:37 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K . V, linux-kernel, Paul Mackerras, Vladis Dronov
Certain warnings are emitted for powerpc code when building with a gcc-10
toolset:
WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
reference from the function remove_pmd_table() to the function
.meminit.text:split_kernel_mapping()
The function remove_pmd_table() references
the function __meminit split_kernel_mapping().
This is often because remove_pmd_table lacks a __meminit
annotation or the annotation of split_kernel_mapping is wrong.
Add the appropriate __init and __meminit annotations to make modpost not
complain. In all the cases there are just a single callsite from another
__init or __meminit function:
__meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
__init prom_init() -> setup_secure_guest()
__init xive_spapr_init() -> xive_spapr_disabled()
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
---
arch/powerpc/kernel/prom_init.c | 4 ++--
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
arch/powerpc/sysdev/xive/spapr.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 90c604d00b7d..f6ca7f450361 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3262,7 +3262,7 @@ static int enter_secure_mode(unsigned long kbase, unsigned long fdt)
/*
* Call the Ultravisor to transfer us to secure memory if we have an ESM blob.
*/
-static void setup_secure_guest(unsigned long kbase, unsigned long fdt)
+static void __init setup_secure_guest(unsigned long kbase, unsigned long fdt)
{
int ret;
@@ -3292,7 +3292,7 @@ static void setup_secure_guest(unsigned long kbase, unsigned long fdt)
}
}
#else
-static void setup_secure_guest(unsigned long kbase, unsigned long fdt)
+static void __init setup_secure_guest(unsigned long kbase, unsigned long fdt)
{
}
#endif /* CONFIG_PPC_SVM */
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index bb00e0cba119..b868c07110e3 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -800,7 +800,7 @@ static void __meminit split_kernel_mapping(unsigned long addr, unsigned long end
pte_clear(&init_mm, addr, pte);
}
-static void remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
+static void __meminit remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
unsigned long end)
{
unsigned long next;
@@ -825,7 +825,7 @@ static void remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
}
}
-static void remove_pud_table(pud_t *pud_start, unsigned long addr,
+static void __meminit remove_pud_table(pud_t *pud_start, unsigned long addr,
unsigned long end)
{
unsigned long next;
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index f0551a2be9df..1e3674d7ea7b 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -768,7 +768,7 @@ static const u8 *get_vec5_feature(unsigned int index)
return vec5 + index;
}
-static bool xive_spapr_disabled(void)
+static bool __init xive_spapr_disabled(void)
{
const u8 *vec5_xive;
--
2.26.2
^ permalink raw reply related
* Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault
From: Michael Ellerman @ 2020-07-29 13:58 UTC (permalink / raw)
To: Nicholas Piggin, Linus Torvalds
Cc: linux-arch, Hillf Danton, mm-commits, Catalin Marinas,
Hugh Dickins, Josef Bacik, Will Deacon, Linux-MM, Matthew Wilcox,
Johannes Weiner, Yu Xu, Andrew Morton, linuxppc-dev, Yang Shi,
Kirill A . Shutemov
In-Reply-To: <1595974242.esf9644sf3.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Linus Torvalds's message of July 29, 2020 5:02 am:
>> On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>>>
>>> The quirk is a problem with coprocessor where it's supposed to
>>> invalidate the translation after a fault but it doesn't, so we can get a
>>> read-only TLB stuck after something else does a RO->RW upgrade on the
>>> TLB. Something like that IIRC. Coprocessors have their own MMU which
>>> lives in the nest not the core, so you need a global TLB flush to
>>> invalidate that thing.
>>
>> So I assumed, but it does seem confused.
>>
>> Why? Because if there are stale translations on the co-processor,
>> there's no guarantee that one of the CPU's will have them and take a
>> fault.
>>
>> So I'm not seeing why a core CPU doing spurious TLB invalidation would
>> follow from "stale TLB in the Nest".
>
> If the nest MMU access faults, it sends an interrupt to the CPU and
> the driver tries to handle the page fault for it (I think that's how
> it works).
Yeah AFAIK. I think they all end up calling copro_handle_mm_fault().
Except for NX/vas, where the model is a fault just causes the request to
be dropped and sent back to userspace to fix things up.
cheers
^ permalink raw reply
* Re: [PATCH v2] selftests: powerpc: Fix online CPU selection
From: Michael Ellerman @ 2020-07-29 13:47 UTC (permalink / raw)
To: Sandipan Das; +Cc: srikar, kamalesh, shiganta, nasastry, harish, linuxppc-dev
In-Reply-To: <20200609073733.997643-1-sandipan@linux.ibm.com>
Sandipan Das <sandipan@linux.ibm.com> writes:
> The size of the CPU affinity mask must be large enough for
> systems with a very large number of CPUs. Otherwise, tests
> which try to determine the first online CPU by calling
> sched_getaffinity() will fail. This makes sure that the size
> of the allocated affinity mask is dependent on the number of
> CPUs as reported by get_nprocs().
>
> Fixes: 3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
> Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> ---
> Previous versions can be found at:
> v1: https://lore.kernel.org/linuxppc-dev/20200608144212.985144-1-sandipan@linux.ibm.com/
>
> Changes in v2:
> - Added NULL check for the affinity mask as suggested by Kamalesh.
> - Changed "cpu set" to "CPU affinity mask" in the commit message.
This sometimes breaks, eg:
# ./count_instructions
test: count_instructions
tags: git_version:v5.8-rc2-327-g9a1d992a7eb7
sched_getaffinity: Invalid argument
[FAIL] Test FAILED on line 123
failure: count_instructions
This system has a messed up SMT setup, but the old code was able to cope
with it:
# ppc64_cpu --info
Core 0: 0* 1* 2 3 4 5 6 7
Core 1: 8 9 10* 11* 12 13 14 15
Core 2: 16 17 18 19 20 21 22 23
Core 3: 24 25 26 27 28 29 30 31
Core 4: 32 33 34 35 36 37 38 39
Core 5: 40 41 42 43 44 45 46 47
Core 6: 48 49 50 51 52 53 54 55
Core 7: 56 57 58 59 60 61 62 63
Core 8: 64 65 66 67 68 69 70 71
Core 9: 72 73 74 75 76 77 78 79
Core 10: 80 81 82 83 84 85 86 87
Core 11: 88 89 90 91 92 93 94 95
Core 12: 96 97 98 99 100* 101* 102* 103*
Core 13: 104* 105* 106* 107* 108* 109* 110* 111*
Core 14: 112* 113* 114* 115* 116* 117* 118* 119*
Core 15: 120 121 122 123 124 125 126 127
Core 16: 128 129 130 131 132 133 134 135
Core 17: 136 137 138 139 140 141 142 143
Core 18: 144 145 146 147 148 149 150 151
Core 19: 152 153 154 155 156 157 158 159
cheers
^ permalink raw reply
* Re: ASMedia ASM2142 USB host controller tries to DMA to address zero when doing bulk reads from multiple devices
From: Oliver O'Halloran @ 2020-07-29 13:22 UTC (permalink / raw)
To: Forest Crossman; +Cc: Alexey Kardashevskiy, linux-usb, linuxppc-dev
In-Reply-To: <CAO3ALPyB1JDvvC27JGgAoTuHh0w+897tPhmTKX9PQWBFCrrnbQ@mail.gmail.com>
On Tue, Jul 21, 2020 at 3:51 PM Forest Crossman <cyrozap@gmail.com> wrote:
>
> Hello, again!
>
> After fixing the issue in my previous thread using this patch[1], I
> decided to do some stress-testing of the controller to make sure it
> could handle my intended workloads and that there were no further DMA
> address issues that would need to be fixed. Unfortunately, it looks
> like there's still more work to be done: when I try to do long bulk
> reads from multiple devices simultaneously, eventually the host
> controller sends a DMA write to address zero, which then triggers EEH
> in my POWER9 system, causing the controller card to get hotplug-reset,
> which of course kills the disk-reading processes. For more details on
> the EEH errors, you can see my kernel's EEH message log[2].
Take the logged address with a grain of salt. If an error occurs while
translating the DMA address the PHB logs all zeros as the "DMA
Address" because it only keeps around the bits that it needs to fetch
the next level of the TCE table. The EEH dump says the error is due to
a TCE permission mis-match so odds the ASmedia controller is writing
to an address that's already been DMA unmapped, hence the logged
address being zeros.
Sorry, I probably should have mentioned that quirk in the last mail.
> The results of the various tests I performed are listed below.
>
> Test results (all failures are due to DMA writes to address zero, all
> hubs are USB 3.0/3.1 Gen1 only, and all disks are accessed via the
> usb-storage driver):
> - Reading simultaneously from two or more disks behind a hub connected
> to one port on the host controller:
> - FAIL after 20-50 GB of data transferred for each device.
> - Reading simultaneously from two disks, each connected directly to
> one port on the host controller:
> - FAIL after about 800 GB of data transferred for each device.
> - Reading from one disk behind a hub connected to one port on the host
> controller:
> - OK for at least 2.7 TB of data transferred (I didn't test the
> whole 8 TB disk).
> - Writing simultaneously to two FL2000 dongles (using osmo-fl2k's
> "fl2k_test"), each connected directly to one port on the host
> controller:
> - OK, was able to write several dozen terabytes to each device over
> the course of a little over 21 hours.
>
> Seeing how simultaneous writes to multiple devices and reads from
> single devices both seem to work fine, I assume that means this is
> being caused by some race condition in the host controller firmware
> when it responds to multiple read requests.
Most likely. It's possible it's a platform specific race with DMA
map/unmap too, but I think we would be seeing similar issues with
other devices if it was.
> I also assume we're not
> going to be able to convince ASMedia to both fix the bug in their
> firmware and release the details on how to flash it from Linux, so I
> guess we'll just have to figure out how to make the driver talk to the
> controller in a way that avoids triggering the bad DMA write. As
> before, I decided to try a little kernel hacking of my own before
> sending this email, and tried separately enabling the
> XHCI_BROKEN_STREAMS and XHCI_ASMEDIA_MODIFY_FLOWCONTROL quirks in an
> attempt to fix this. As you might expect since you're reading this
> message, neither of those quirks fixed the issue, nor did they even
> make the transfers last any longer before failing.
>
> So now I've reached the limits of my understanding, and I need some
> help devising a fix. If anyone has any comments to that effect, or any
> questions about my hardware configuration, testing methodology, etc.,
> please don't hesitate to air them. Also, if anyone needs me to perform
> additional tests, or collect more log information, I'd be happy to do
> that as well.
I started writing a tool a while ago to use the internal trace bus to
log incoming TLPs. Something like that might allow you to get a better
idea what the faulting access pattern is, but you would still need to
find a way to mitigate the issue. I'm not all that familiar with USB3
so I'm not much help on that front.
^ permalink raw reply
* Re: [PATCH 0/7] Optimization to improve cpu online/offline on Powerpc
From: Satheesh Rajendran @ 2020-07-29 12:54 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Michael Neuling, Peter Zijlstra,
LKML, Nicholas Piggin, Valentin Schneider, Oliver O'Halloran,
Satheesh Rajendran, linuxppc-dev, Ingo Molnar
In-Reply-To: <20200727075532.30058-1-srikar@linux.vnet.ibm.com>
On Mon, Jul 27, 2020 at 01:25:25PM +0530, Srikar Dronamraju wrote:
> Anton reported that his 4096 cpu (1024 cores in a socket) was taking too
> long to boot. He also analyzed that most of the time was being spent on
> updating cpu_core_mask.
>
> Here are some optimizations and fixes to make ppc64_cpu --smt=8/ppc64_cpu
> --smt=1 run faster and hence boot the kernel also faster.
>
> Its based on top of my v4 coregroup support patchset.
> http://lore.kernel.org/lkml/20200727053230.19753-1-srikar@linux.vnet.ibm.com/t/#u
>
> The first two patches should solve Anton's immediate problem.
> On the unofficial patches, Anton reported that the boot time came from 30
> mins to 6 seconds. (Basically a high core count in a single socket
> configuration). Satheesh also reported similar numbers.
>
> The rest are simple cleanups/optimizations.
>
> Since cpu_core_mask is an exported symbol for a long duration, lets retain
> as a snapshot of cpumask_of_node.
boot tested on P9 KVM guest.
without this series:
# dmesg|grep smp
[ 0.066624] smp: Bringing up secondary CPUs ...
[ 347.521264] smp: Brought up 1 node, 2048 CPUs
with this series:
# dmesg|grep smp
[ 0.067744] smp: Bringing up secondary CPUs ...
[ 5.416910] smp: Brought up 1 node, 2048 CPUs
Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Regards,
-Satheesh
>
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 160
> On-line CPU(s) list: 0-159
> Thread(s) per core: 4
> Core(s) per socket: 20
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9, altivec supported
> CPU max MHz: 3800.0000
> CPU min MHz: 2166.0000
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 512K
> L3 cache: 10240K
> NUMA node0 CPU(s): 0-79
> NUMA node8 CPU(s): 80-159
>
> without patch (powerpc/next)
> [ 0.099347] smp: Bringing up secondary CPUs ...
> [ 0.832513] smp: Brought up 2 nodes, 160 CPUs
>
> with powerpc/next + coregroup support patchset
> [ 0.099241] smp: Bringing up secondary CPUs ...
> [ 0.835627] smp: Brought up 2 nodes, 160 CPUs
>
> with powerpc/next + coregroup + this patchset
> [ 0.097232] smp: Bringing up secondary CPUs ...
> [ 0.528457] smp: Brought up 2 nodes, 160 CPUs
>
> x ppc64_cpu --smt=1
> + ppc64_cpu --smt=4
>
> without patch
> N Min Max Median Avg Stddev
> x 100 11.82 17.06 14.01 14.05 1.2665247
> + 100 12.25 16.59 13.86 14.1143 1.164293
>
> with patch
> N Min Max Median Avg Stddev
> x 100 12.68 16.15 14.24 14.238 0.75489246
> + 100 12.93 15.85 14.35 14.2897 0.60041813
>
> Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
> Cc: LKML <linux-kernel@vger.kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Anton Blanchard <anton@ozlabs.org>
> Cc: Oliver O'Halloran <oohall@gmail.com>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Cc: Michael Neuling <mikey@neuling.org>
> Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
> Cc: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Valentin Schneider <valentin.schneider@arm.com>
>
> Srikar Dronamraju (7):
> powerpc/topology: Update topology_core_cpumask
> powerpc/smp: Stop updating cpu_core_mask
> powerpc/smp: Remove get_physical_package_id
> powerpc/smp: Optimize remove_cpu_from_masks
> powerpc/smp: Limit cpus traversed to within a node.
> powerpc/smp: Stop passing mask to update_mask_by_l2
> powerpc/smp: Depend on cpu_l1_cache_map when adding cpus
>
> arch/powerpc/include/asm/smp.h | 5 --
> arch/powerpc/include/asm/topology.h | 7 +--
> arch/powerpc/kernel/smp.c | 79 +++++++++--------------------
> 3 files changed, 24 insertions(+), 67 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/pci: Fix build of pci-ioda.o
From: Gustavo Romero @ 2020-07-29 12:31 UTC (permalink / raw)
To: Oliver O'Halloran, Gustavo Romero; +Cc: linuxppc-dev
In-Reply-To: <CAOSf1CG4b_G_dzb2f2pRo-P=Ku4f7QB8VJpRmGjejHi+R2qQGg@mail.gmail.com>
Hi Oliver,
On 7/28/20 7:50 PM, Oliver O'Halloran wrote:
> On Wed, Jul 29, 2020 at 8:35 AM Gustavo Romero <gromero@linux.ibm.com> wrote:
>>
>> Currently pnv_ioda_setup_bus_dma() is outside of a CONFIG_IOMMU_API guard
>> and if CONFIG_IOMMU_API=n the build can fail if the compiler sets
>> -Werror=unused-function, because pnv_ioda_setup_bus_dma() is only used in
>> functions guarded by a CONFIG_IOMMU_API guard.
>>
>> That issue can be easily reproduced using the skiroot_defconfig. For other
>> configs, like powernv_defconfig, that issue is hidden by the fact that
>> if CONFIG_IOMMU_SUPPORT is enabled plus other common IOMMU options, like
>> CONFIG_OF_IOMMU, by default CONFIG_IOMMU_API is enabled as well. Hence, for
>> powernv_defconfig, it's necessary to set CONFIG_IOMMU_SUPPORT=n to make the
>> build fail, because CONFIG_PCI=y and pci-ioda.c is included in the build,
>> but since CONFIG_IOMMU_SUPPORT=n the CONFIG_IOMMU_API is disabled, breaking
>> the build.
>>
>> This commit fixes that build issue by moving the pnv_ioda_setup_bus_dma()
>> inside a CONFIG_IOMMU_API guard, so when CONFIG_IOMMU_API is disabled that
>> function is not defined.
>
> I think a fix for this is already in -next.
Indeed.
For the records, it's fixed in -next by:
commit e3417faec526cbf97773dca691dcd743f5bfeb64
Author: Oliver O'Halloran <oohall@gmail.com>
Date: Sun Jul 5 23:35:57 2020 +1000
powerpc/powernv: Move pnv_ioda_setup_bus_dma under CONFIG_IOMMU_API
pnv_ioda_setup_bus_dma() is only used when a passed through PE is
returned to the host. If the kernel is built without IOMMU support
this is dead code. Move it under the #ifdef with the rest of the
IOMMU API support.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200705133557.443607-2-oohall@gmail.com
Thanks.
Cheers,
Gustavo
^ 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