Re: Patches for ARC
On Mon, Jun 13, 2016 at 11:38 PM, Waldemar Brodkorb wrote: > @Max: Okay to add you as Xtensa maintainer? Sure, thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: arc_usr_cmpxchg and preemption
> On Thu, Mar 15, 2018 at 12:03 PM, Alexey Brodkin
> wrote:
> Here's a brief analysis:
> ARM: Looks like they got rid of that stuff in v4.4, see
> commit db695c0509d6 ("ARM: remove user cmpxchg syscall").
>
> M68K: That's even uglier implementation which is really asking for
> a facelift, look at sys_atomic_cmpxchg_32() here:
>
> https://elixir.bootlin.com/linux/latest/source/arch/m68k/kernel/sys_m68k.c#L461
>
> MIPS: They do it via special sysmips syscall which among other things
> might handle MIPS_ATOMIC_SET with mips_atomic_set()
>
> I don't immediately see if there're others but really I'm not sure if it even
> worth trying to
> clean-up all that since efforts might be spent pointlessly.
xtensa is another one. We used to have a buggy implementation in
arch/xtensa/kernel/entry.S:fast_syscall_xtensa which we still keep
disabled by default, just in case somebody wanted backwards
compatibility. I don't think it's worth fixing.
--
Thanks.
-- Max
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Mon, Jan 21, 2019 at 12:06 AM Mike Rapoport wrote:
>
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Guo Ren # c-sky
> Acked-by: Paul Burton # MIPS
> Acked-by: Heiko Carstens # s390
> Reviewed-by: Juergen Gross # Xen
> ---
> arch/xtensa/mm/kasan_init.c | 4 ++++
> arch/xtensa/mm/mmu.c | 3 +++
For xtensa:
Acked-by: Max Filippov
--
Thanks.
-- Max
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args
On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > After removing the start and count arguments of syscall_get_arguments() it > seems reasonable to remove them from syscall_set_arguments(). Note, as of > today, there are no users of syscall_set_arguments(). But we are told that > there will be soon. But for now, at least make it consistent with > syscall_get_arguments(). [...] > arch/xtensa/include/asm/syscall.h | 17 ++----- For xtensa changes: Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args
On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt wrote: > > From: "Steven Rostedt (Red Hat)" > > At Linux Plumbers, Andy Lutomirski approached me and pointed out that the > function call syscall_get_arguments() implemented in x86 was horribly > written and not optimized for the standard case of passing in 0 and 6 for > the starting index and the number of system calls to get. When looking at > all the users of this function, I discovered that all instances pass in only > 0 and 6 for these arguments. Instead of having this function handle > different cases that are never used, simply rewrite it to return the first 6 > arguments of a system call. > > This should help out the performance of tracing system calls by ptrace, > ftrace and perf. [...] > arch/xtensa/include/asm/syscall.h | 16 ++ For xtensa changes: Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig
On Fri, Jul 30, 2021 at 10:24 PM Masahiro Yamada wrote: > > Make architectures select TRACE_IRQFLAGS_SUPPORT instead of > having many defines. > > Signed-off-by: Masahiro Yamada > --- > arch/xtensa/Kconfig | 4 +--- Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] futex: remove futex_cmpxchg detection
On Tue, Oct 26, 2021 at 3:06 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > Now that all architectures have a working futex implementation > in any configuration, remove the runtime detection code. > > Signed-off-by: Arnd Bergmann > --- > arch/arc/Kconfig | 1 - > arch/arm/Kconfig | 1 - > arch/arm64/Kconfig| 1 - > arch/csky/Kconfig | 1 - > arch/m68k/Kconfig | 1 - > arch/riscv/Kconfig| 1 - > arch/s390/Kconfig | 1 - > arch/sh/Kconfig | 1 - > arch/um/Kconfig | 1 - > arch/um/kernel/skas/uaccess.c | 1 - > arch/xtensa/Kconfig | 1 - > init/Kconfig | 8 > kernel/futex/core.c | 35 --- > kernel/futex/futex.h | 6 -- > kernel/futex/syscalls.c | 22 ------ > 15 files changed, 82 deletions(-) For xtensa: Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3] mm: Avoid unnecessary page fault retires on shared memory types
On Tue, May 24, 2022 at 4:45 PM Peter Xu wrote: > > I observed that for each of the shared file-backed page faults, we're very > likely to retry one more time for the 1st write fault upon no page. It's > because we'll need to release the mmap lock for dirty rate limit purpose > with balance_dirty_pages_ratelimited() (in fault_dirty_shared_page()). > > Then after that throttling we return VM_FAULT_RETRY. > > We did that probably because VM_FAULT_RETRY is the only way we can return > to the fault handler at that time telling it we've released the mmap lock. > > However that's not ideal because it's very likely the fault does not need > to be retried at all since the pgtable was well installed before the > throttling, so the next continuous fault (including taking mmap read lock, > walk the pgtable, etc.) could be in most cases unnecessary. > > It's not only slowing down page faults for shared file-backed, but also add > more mmap lock contention which is in most cases not needed at all. > > To observe this, one could try to write to some shmem page and look at > "pgfault" value in /proc/vmstat, then we should expect 2 counts for each > shmem write simply because we retried, and vm event "pgfault" will capture > that. > > To make it more efficient, add a new VM_FAULT_COMPLETED return code just to > show that we've completed the whole fault and released the lock. It's also > a hint that we should very possibly not need another fault immediately on > this page because we've just completed it. > > This patch provides a ~12% perf boost on my aarch64 test VM with a simple > program sequentially dirtying 400MB shmem file being mmap()ed and these are > the time it needs: > > Before: 650.980 ms (+-1.94%) > After: 569.396 ms (+-1.38%) > > I believe it could help more than that. > > We need some special care on GUP and the s390 pgfault handler (for gmap > code before returning from pgfault), the rest changes in the page fault > handlers should be relatively straightforward. > > Another thing to mention is that mm_account_fault() does take this new > fault as a generic fault to be accounted, unlike VM_FAULT_RETRY. > > I explicitly didn't touch hmm_vma_fault() and break_ksm() because they do > not handle VM_FAULT_RETRY even with existing code, so I'm literally keeping > them as-is. > > Signed-off-by: Peter Xu > --- > > v3: > - Rebase to akpm/mm-unstable > - Copy arch maintainers > --- For xtensa: Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 11/24] xtensa: Remove COMMAND_LINE_SIZE from uapi
On Tue, Feb 14, 2023 at 12:01 AM Alexandre Ghiti wrote: > > From: Palmer Dabbelt > > As far as I can tell this is not used by userspace and thus should not > be part of the user-visible API. > > Signed-off-by: Palmer Dabbelt > --- > arch/xtensa/include/asm/setup.h | 17 + > arch/xtensa/include/uapi/asm/setup.h | 2 -- > 2 files changed, 17 insertions(+), 2 deletions(-) > create mode 100644 arch/xtensa/include/asm/setup.h Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 21/24] xtensa: Remove empty
On Tue, Feb 14, 2023 at 12:11 AM Alexandre Ghiti wrote: > > From: Palmer Dabbelt > > Signed-off-by: Palmer Dabbelt > --- > arch/xtensa/include/uapi/asm/setup.h | 15 --- > 1 file changed, 15 deletions(-) > delete mode 100644 arch/xtensa/include/uapi/asm/setup.h Acked-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/21] xtensa: dma-mapping: use normal cache invalidation rules
On Mon, Mar 27, 2023 at 5:14 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > xtensa is one of the platforms that has both write-back and write-through > caches, and needs to account for both in its DMA mapping operations. > > It does this through a set of operations that is different from any > architecture. This is not a problem by itself, but it makes it rather > hard to figure out whether this is correct or not, and to unify this > implementation with the others. > > Change the semantics to the usual ones for non-speculating CPUs: > > - On DMA_TO_DEVICE, call __flush_dcache_range() to perform the >writeback even on writethrough caches, where this is a nop. > > - On DMA_FROM_DEVICE, invalidate the mapping before the DMA rather >than afterwards. > > - On DMA_BIDIRECTIONAL, combine the pre-writeback with the >post-invalidate into a call to __flush_invalidate_dcache_range() >that turns into a simple invalidate on writeback caches. > > Signed-off-by: Arnd Bergmann > --- > arch/xtensa/Kconfig | 1 - > arch/xtensa/include/asm/cacheflush.h | 6 +++--- > arch/xtensa/kernel/pci-dma.c | 29 +------- > 3 files changed, 8 insertions(+), 28 deletions(-) Reviewed-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 08/13] xtensa: split out printing of virtual memory layout to a function
On Thu, Mar 13, 2025 at 4:52 PM Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" > > This will help with pulling out memblock_free_all() to the generic > code and reducing code duplication in arch::mem_init(). > > Signed-off-by: Mike Rapoport (Microsoft) > --- > arch/xtensa/mm/init.c | 97 ++- > 1 file changed, 50 insertions(+), 47 deletions(-) Reviewed-by: Max Filippov -- Thanks. -- Max ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
