Re: [PATCH 02/12] arm: nommu: use pgtable-nopud instead of 4level-fixup
On Wed, Oct 23, 2019 at 12:28:51PM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > The generic nommu implementation of page table manipulation takes care of > folding of the upper levels and does not require fixups. > > Simply replace of include/asm-generic/4level-fixup.h with > include/asm-generic/pgtable-nopud.h. > > Signed-off-by: Mike Rapoport Acked-by: Russell King Thanks. > --- > arch/arm/include/asm/pgtable.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h > index 3ae120c..eabcb48 100644 > --- a/arch/arm/include/asm/pgtable.h > +++ b/arch/arm/include/asm/pgtable.h > @@ -12,7 +12,7 @@ > > #ifndef CONFIG_MMU > > -#include > +#include > #include > > #else > -- > 2.7.4 > > -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v5 3/3] locking/rwsem: Optimize down_read_trylock()
On Fri, Mar 22, 2019 at 10:30:08AM -0400, Waiman Long wrote: > Modify __down_read_trylock() to optimize for an unlocked rwsem and make > it generate slightly better code. > > Before this patch, down_read_trylock: > >0x <+0>: callq 0x5 >0x0005 <+5>: jmp0x18 >0x0007 <+7>: lea0x1(%rdx),%rcx >0x000b <+11>:mov%rdx,%rax >0x000e <+14>:lock cmpxchg %rcx,(%rdi) >0x0013 <+19>:cmp%rax,%rdx >0x0016 <+22>:je 0x23 >0x0018 <+24>:mov(%rdi),%rdx >0x001b <+27>:test %rdx,%rdx >0x001e <+30>:jns0x7 >0x0020 <+32>:xor%eax,%eax >0x0022 <+34>:retq >0x0023 <+35>:mov%gs:0x0,%rax >0x002c <+44>:or $0x3,%rax >0x0030 <+48>:mov%rax,0x20(%rdi) >0x0034 <+52>:mov$0x1,%eax >0x0039 <+57>:retq > > After patch, down_read_trylock: > >0x <+0>: callq 0x5 >0x0005 <+5>: xor%eax,%eax >0x0007 <+7>: lea0x1(%rax),%rdx >0x000b <+11>: lock cmpxchg %rdx,(%rdi) >0x0010 <+16>: jne0x29 >0x0012 <+18>: mov%gs:0x0,%rax >0x001b <+27>: or $0x3,%rax >0x001f <+31>: mov%rax,0x20(%rdi) >0x0023 <+35>: mov$0x1,%eax >0x0028 <+40>: retq >0x0029 <+41>: test %rax,%rax >0x002c <+44>: jns0x7 >0x002e <+46>: xor%eax,%eax >0x0030 <+48>: retq > > By using a rwsem microbenchmark, the down_read_trylock() rate (with a > load of 10 to lengthen the lock critical section) on a x86-64 system > before and after the patch were: > > Before PatchAfter Patch ># of Threads rlock rlock > - - > 1 14,496 14,716 > 28,644 8,453 > 46,799 6,983 > 85,664 7,190 > > On a ARM64 system, the performance results were: > > Before PatchAfter Patch ># of Threads rlock rlock > - - > 1 23,676 24,488 > 27,697 9,502 > 44,945 3,440 > 82,641 1,603 > > For the uncontended case (1 thread), the new down_read_trylock() is a > little bit faster. For the contended cases, the new down_read_trylock() > perform pretty well in x86-64, but performance degrades at high > contention level on ARM64. So, 70% for 4 threads, 61% for 4 threads - does this trend continue tailing off as the number of threads (and cores) increase? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v2 07/29] ARM: add kexec_file_load system call number
On Fri, Jan 25, 2019 at 03:43:59PM +, Catalin Marinas wrote: > On Fri, Jan 18, 2019 at 05:18:13PM +0100, Arnd Bergmann wrote: > > diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl > > index 86de9eb34296..20ed7e026723 100644 > > --- a/arch/arm/tools/syscall.tbl > > +++ b/arch/arm/tools/syscall.tbl > > @@ -415,3 +415,4 @@ > > 398common rseqsys_rseq > > 399common io_pgetevents sys_io_pgetevents > > 400common migrate_pages sys_migrate_pages > > +401common kexec_file_load sys_kexec_file_load > > I presume on arm32 this would still return -ENOSYS. Yes, I already checked. If CONFIG_KEXEC_FILE is not set, then kernel/kexec_file.c is not built, and we fall back to the stub in kernel/sys_ni.c. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > > - Once we get to 512, we clash with the x32 numbers (unless > > > > we remove x32 support first), and probably have to skip > > > > a few more. I also considered using the 512..547 space > > > > for 32-bit-only calls (which never clash with x32), but > > > > that also seems to add a bit of complexity. > > > > > > I have a patch that I'll send soon to make x32 use its own table. As > > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > > > not special. But let's please not reuse 512..547 for other purposes > > > on x86 variants -- that way lies even more confusion, IMO. > > > > Fair enough, the space for those numbers is cheap enough here. > > I take it you mean we also should not reuse that number space if > > we were to decide to remove x32 soon, but you are not worried > > about clashing with arch/alpha when everything else uses consistent > > numbers? > > > > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something else. Perhaps more importantly, due to > what is arguably a rather severe bug, issuing a native x86_64 syscall > (x32 bit clear) with nr in the range 512..547 does *not* return > -ENOSYS on a kernel with x32 enabled. Instead it does something that > is somewhat arbitrary. With my patch applied, it will return -ENOSYS, > but old kernels will still exist, and this will break syscall probing. > > Can we perhaps just start the consistent numbers above 547 or maybe > block out 512..547 in the new regime? I don't think you gain much with that kind of scheme - it won't take very long before an architecture misses having a syscall added, and then someone else adds their own. Been there with ARM - I was keeping the syscall table in the same order as x86 for new syscalls, but now that others have been adding syscalls to the table since I converted ARM to the tabular form, that's now gone out the window. So, I think it's completely pointless to do what you're suggesting. We'll just end up with a big hole in the middle of the syscall table and then revert back to random numbering of syscalls thereafter again. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH 15/15] arch: add pkey and rseq syscall numbers everywhere
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote: > Most architectures define system call numbers for the rseq and pkey system > calls, even when they don't support the features, and perhaps never will. > > Only a few architectures are missing these, so just define them anyway > for consistency. If we decide to add them later to one of these, the > system call numbers won't get out of sync then. I was lambasted for adding the pkey syscalls for 32-bit ARM in 2016, which will probably never support it. Why has the attitude towards this kind of thing now apparently become acceptable? > Signed-off-by: Arnd Bergmann > --- > arch/alpha/include/asm/unistd.h | 4 > arch/alpha/kernel/syscalls/syscall.tbl | 4 > arch/ia64/kernel/syscalls/syscall.tbl | 4 > arch/m68k/kernel/syscalls/syscall.tbl | 4 > arch/parisc/include/asm/unistd.h| 3 --- > arch/parisc/kernel/syscalls/syscall.tbl | 4 > arch/s390/include/asm/unistd.h | 3 --- > arch/s390/kernel/syscalls/syscall.tbl | 3 +++ > arch/sh/kernel/syscalls/syscall.tbl | 4 > arch/sparc/include/asm/unistd.h | 5 - > arch/sparc/kernel/syscalls/syscall.tbl | 4 > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + > 12 files changed, 28 insertions(+), 15 deletions(-) > > diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h > index 564ba87bdc38..31ad350b58a0 100644 > --- a/arch/alpha/include/asm/unistd.h > +++ b/arch/alpha/include/asm/unistd.h > @@ -29,9 +29,5 @@ > #define __IGNORE_getppid > #define __IGNORE_getuid > > -/* Alpha doesn't have protection keys. */ > -#define __IGNORE_pkey_mprotect > -#define __IGNORE_pkey_alloc > -#define __IGNORE_pkey_free > > #endif /* _ALPHA_UNISTD_H */ > diff --git a/arch/alpha/kernel/syscalls/syscall.tbl > b/arch/alpha/kernel/syscalls/syscall.tbl > index b0e247287908..25b4a7e76943 100644 > --- a/arch/alpha/kernel/syscalls/syscall.tbl > +++ b/arch/alpha/kernel/syscalls/syscall.tbl > @@ -452,3 +452,7 @@ > 521 common pwritev2sys_pwritev2 > 522 common statx sys_statx > 523 common io_pgetevents sys_io_pgetevents > +524 common pkey_alloc sys_pkey_alloc > +525 common pkey_free sys_pkey_free > +526 common pkey_mprotect sys_pkey_mprotect > +527 common rseqsys_rseq > diff --git a/arch/ia64/kernel/syscalls/syscall.tbl > b/arch/ia64/kernel/syscalls/syscall.tbl > index 2e93dbdcdb80..84e03de00177 100644 > --- a/arch/ia64/kernel/syscalls/syscall.tbl > +++ b/arch/ia64/kernel/syscalls/syscall.tbl > @@ -339,3 +339,7 @@ > 327 common io_pgetevents sys_io_pgetevents > 328 common perf_event_open sys_perf_event_open > 329 common seccomp sys_seccomp > +330 common pkey_alloc sys_pkey_alloc > +331 common pkey_free sys_pkey_free > +332 common pkey_mprotect sys_pkey_mprotect > +333 common rseqsys_rseq > diff --git a/arch/m68k/kernel/syscalls/syscall.tbl > b/arch/m68k/kernel/syscalls/syscall.tbl > index 5354ba02eed2..ae88b85d068e 100644 > --- a/arch/m68k/kernel/syscalls/syscall.tbl > +++ b/arch/m68k/kernel/syscalls/syscall.tbl > @@ -388,6 +388,10 @@ > 378 common pwritev2sys_pwritev2 > 379 common statx sys_statx > 380 common seccomp sys_seccomp > +381 common pkey_alloc sys_pkey_alloc > +382 common pkey_free sys_pkey_free > +383 common pkey_mprotect sys_pkey_mprotect > +384 common rseqsys_rseq > # room for arch specific calls > 393 common semget sys_semget > 394 common semctl sys_semctl > diff --git a/arch/parisc/include/asm/unistd.h > b/arch/parisc/include/asm/unistd.h > index c2c2afb28941..9ec1026af877 100644 > --- a/arch/parisc/include/asm/unistd.h > +++ b/arch/parisc/include/asm/unistd.h > @@ -12,9 +12,6 @@ > > #define __IGNORE_select /* newselect */ > #define __IGNORE_fadvise64 /* fadvise64_64 */ > -#define __IGNORE_pkey_mprotect > -#define __IGNORE_pkey_alloc > -#define __IGNORE_pkey_free > > #ifndef ASM_LINE_SEP > # define ASM_LINE_SEP ; > diff --git a/arch/parisc/kernel/syscalls/syscall.tbl > b/arch/parisc/kernel/syscalls/syscall.tbl > index 9bbd2f9f56c8..e07231de3597 100644 > --- a/arch/parisc/kernel/syscalls/syscall.tbl > +++ b/arch/parisc/kernel/syscalls/syscall.tbl > @@ -367,3 +367,7 @@ > 348 common pwritev2sys_pwritev2 > compat_sys_pwritev2 > 349 common statx sys_statx > 350 common io_pgetevents sys_io_pgetevents >
