An error occurred fetching the project authors.
  1. 30 Apr, 2024 1 commit
    • Jisheng Zhang's avatar
      riscv: select ARCH_HAS_FAST_MULTIPLIER · 48b4fc66
      Jisheng Zhang authored
      Currently, riscv linux requires at least IMA, so all platforms have a
      multiplier. And I assume the 'mul' efficiency is comparable or better
      than a sequence of five or so register-dependent arithmetic
      instructions. Select ARCH_HAS_FAST_MULTIPLIER to get slightly nicer
      codegen. Refer to commit f9b41929 ("[PATCH] bitops: hweight()
      speedup") for more details.
      
      In a simple benchmark test calling hweight64() in a loop, it got:
      about 14% performance improvement on JH7110, tested on Milkv Mars.
      
      about 23% performance improvement on TH1520 and SG2042, tested on
      Sipeed LPI4A and SG2042 platform.
      
      a slight performance drop on CV1800B, tested on milkv duo. Among all
      riscv platforms in my hands, this is the only one which sees a slight
      performance drop. It means the 'mul' isn't quick enough. However, the
      situation exists on x86 too, for example, P4 doesn't have fast
      integer multiplies as said in the above commit, x86 also selects
      ARCH_HAS_FAST_MULTIPLIER. So let's select ARCH_HAS_FAST_MULTIPLIER
      which can benefit almost riscv platforms.
      
      Samuel also provided some performance numbers:
      On Unmatched: 20% speedup for __sw_hweight32 and 30% speedup for
      __sw_hweight64.
      On D1: 8% speedup for __sw_hweight32 and 8% slowdown for
      __sw_hweight64.
      Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
      Reviewed-by: default avatarSamuel Holland <samuel.holland@sifive.com>
      Tested-by: default avatarSamuel Holland <samuel.holland@sifive.com>
      Reviewed-by: default avatarAlexandre Ghiti <alexghiti@rivosinc.com>
      Link: https://lore.kernel.org/r/20240325105823.1483-1-jszhang@kernel.orgSigned-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      48b4fc66
  2. 29 Apr, 2024 1 commit
  3. 28 Apr, 2024 1 commit
  4. 26 Apr, 2024 1 commit
  5. 24 Apr, 2024 1 commit
  6. 09 Apr, 2024 2 commits
  7. 25 Mar, 2024 1 commit
  8. 13 Mar, 2024 1 commit
  9. 06 Mar, 2024 2 commits
  10. 28 Feb, 2024 1 commit
  11. 24 Feb, 2024 1 commit
    • Baoquan He's avatar
      kexec: split crashkernel reservation code out from crash_core.c · 85fcde40
      Baoquan He authored
      Patch series "Split crash out from kexec and clean up related config
      items", v3.
      
      Motivation:
      =============
      Previously, LKP reported a building error. When investigating, it can't
      be resolved reasonablly with the present messy kdump config items.
      
       https://lore.kernel.org/oe-kbuild-all/202312182200.Ka7MzifQ-lkp@intel.com/
      
      The kdump (crash dumping) related config items could causes confusions:
      
      Firstly,
      
      CRASH_CORE enables codes including
       - crashkernel reservation;
       - elfcorehdr updating;
       - vmcoreinfo exporting;
       - crash hotplug handling;
      
      Now fadump of powerpc, kcore dynamic debugging and kdump all selects
      CRASH_CORE, while fadump
       - fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing
         global variable 'elfcorehdr_addr';
       - kcore only needs vmcoreinfo exporting;
       - kdump needs all of the current kernel/crash_core.c.
      
      So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this
      mislead people that we enable crash dumping, actual it's not.
      
      Secondly,
      
      It's not reasonable to allow KEXEC_CORE select CRASH_CORE.
      
      Because KEXEC_CORE enables codes which allocate control pages, copy
      kexec/kdump segments, and prepare for switching. These codes are
      shared by both kexec reboot and kdump. We could want kexec reboot,
      but disable kdump. In that case, CRASH_CORE should not be selected.
      
       --------------------
       CONFIG_CRASH_CORE=y
       CONFIG_KEXEC_CORE=y
       CONFIG_KEXEC=y
       CONFIG_KEXEC_FILE=y
       ---------------------
      
      Thirdly,
      
      It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.
      
      That could make KEXEC_CORE, CRASH_DUMP are enabled independently from
      KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE
      code built in doesn't make any sense because no kernel loading or
      switching will happen to utilize the KEXEC_CORE code.
       ---------------------
       CONFIG_CRASH_CORE=y
       CONFIG_KEXEC_CORE=y
       CONFIG_CRASH_DUMP=y
       ---------------------
      
      In this case, what is worse, on arch sh and arm, KEXEC relies on MMU,
      while CRASH_DUMP can still be enabled when !MMU, then compiling error is
      seen as the lkp test robot reported in above link.
      
       ------arch/sh/Kconfig------
       config ARCH_SUPPORTS_KEXEC
               def_bool MMU
      
       config ARCH_SUPPORTS_CRASH_DUMP
               def_bool BROKEN_ON_SMP
       ---------------------------
      
      Changes:
      ===========
      1, split out crash_reserve.c from crash_core.c;
      2, split out vmcore_infoc. from crash_core.c;
      3, move crash related codes in kexec_core.c into crash_core.c;
      4, remove dependency of FA_DUMP on CRASH_DUMP;
      5, clean up kdump related config items;
      6, wrap up crash codes in crash related ifdefs on all 8 arch-es
         which support crash dumping, except of ppc;
      
      Achievement:
      ===========
      With above changes, I can rearrange the config item logic as below (the right
      item depends on or is selected by the left item):
      
          PROC_KCORE -----------> VMCORE_INFO
      
                     |----------> VMCORE_INFO
          FA_DUMP----|
                     |----------> CRASH_RESERVE
      
                                                          ---->VMCORE_INFO
                                                         /
                                                         |---->CRASH_RESERVE
          KEXEC      --|                                /|
                       |--> KEXEC_CORE--> CRASH_DUMP-->/-|---->PROC_VMCORE
          KEXEC_FILE --|                               \ |
                                                         \---->CRASH_HOTPLUG
      
      
          KEXEC      --|
                       |--> KEXEC_CORE (for kexec reboot only)
          KEXEC_FILE --|
      
      Test
      ========
      On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips,
      riscv, loongarch, I did below three cases of config item setting and
      building all passed. Take configs on x86_64 as exampmle here:
      
      (1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump
      items are unset automatically:
      # Kexec and crash features
      # CONFIG_KEXEC is not set
      # CONFIG_KEXEC_FILE is not set
      # end of Kexec and crash features
      
      (2) set CONFIG_KEXEC_FILE and 'make olddefconfig':
      ---------------
      # Kexec and crash features
      CONFIG_CRASH_RESERVE=y
      CONFIG_VMCORE_INFO=y
      CONFIG_KEXEC_CORE=y
      CONFIG_KEXEC_FILE=y
      CONFIG_CRASH_DUMP=y
      CONFIG_CRASH_HOTPLUG=y
      CONFIG_CRASH_MAX_MEMORY_RANGES=8192
      # end of Kexec and crash features
      ---------------
      
      (3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig':
      ------------------------
      # Kexec and crash features
      CONFIG_KEXEC_CORE=y
      CONFIG_KEXEC_FILE=y
      # end of Kexec and crash features
      ------------------------
      
      Note:
      For ppc, it needs investigation to make clear how to split out crash
      code in arch folder. Hope Hari and Pingfan can help have a look, see if
      it's doable. Now, I make it either have both kexec and crash enabled, or
      disable both of them altogether.
      
      
      This patch (of 14):
      
      Both kdump and fa_dump of ppc rely on crashkernel reservation.  Move the
      relevant codes into separate files: crash_reserve.c,
      include/linux/crash_reserve.h.
      
      And also add config item CRASH_RESERVE to control its enabling of the
      codes.  And update config items which has relationship with crashkernel
      reservation.
      
      And also change ifdeffery from CONFIG_CRASH_CORE to CONFIG_CRASH_RESERVE
      when those scopes are only crashkernel reservation related.
      
      And also rename arch/XXX/include/asm/{crash_core.h => crash_reserve.h} on
      arm64, x86 and risc-v because those architectures' crash_core.h is only
      related to crashkernel reservation.
      
      [akpm@linux-foundation.org: s/CRASH_RESEERVE/CRASH_RESERVE/, per Klara Modin]
      Link: https://lkml.kernel.org/r/20240124051254.67105-1-bhe@redhat.com
      Link: https://lkml.kernel.org/r/20240124051254.67105-2-bhe@redhat.comSigned-off-by: default avatarBaoquan He <bhe@redhat.com>
      Acked-by: default avatarHari Bathini <hbathini@linux.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Pingfan Liu <piliu@redhat.com>
      Cc: Klara Modin <klarasmodin@gmail.com>
      Cc: Michael Kelley <mhklinux@outlook.com>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Yang Li <yang.lee@linux.alibaba.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      85fcde40
  12. 22 Feb, 2024 2 commits
  13. 17 Feb, 2024 1 commit
  14. 15 Feb, 2024 2 commits
  15. 06 Feb, 2024 1 commit
    • Kees Cook's avatar
      ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL · 918327e9
      Kees Cook authored
      For simplicity in splitting out UBSan options into separate rules,
      remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which
      is how it is generally used anyway. (There are no ":= y" cases beyond
      where a specific file is enabled when a top-level ":= n" is in effect.)
      
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Marco Elver <elver@google.com>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-kbuild@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      918327e9
  16. 25 Jan, 2024 1 commit
  17. 24 Jan, 2024 2 commits
  18. 23 Jan, 2024 2 commits
  19. 22 Jan, 2024 1 commit
  20. 18 Jan, 2024 5 commits
  21. 16 Jan, 2024 2 commits
  22. 11 Jan, 2024 2 commits
    • Alexandre Ghiti's avatar
      riscv: Add support for BATCHED_UNMAP_TLB_FLUSH · 54d7431a
      Alexandre Ghiti authored
      Allow to defer the flushing of the TLB when unmapping pages, which allows
      to reduce the numbers of IPI and the number of sfence.vma.
      
      The ubenchmarch used in commit 43b3dfdd ("arm64: support
      batched/deferred tlb shootdown during page reclamation/migration") that
      was multithreaded to force the usage of IPI shows good performance
      improvement on all platforms:
      
      * Unmatched: ~34%
      * TH1520   : ~78%
      * Qemu     : ~81%
      
      In addition, perf on qemu reports an important decrease in time spent
      dealing with IPIs:
      
      Before:  68.17%  main     [kernel.kallsyms]            [k] __sbi_rfence_v02_call
      After :   8.64%  main     [kernel.kallsyms]            [k] __sbi_rfence_v02_call
      
      * Benchmark:
      
      int stick_this_thread_to_core(int core_id) {
              int num_cores = sysconf(_SC_NPROCESSORS_ONLN);
              if (core_id < 0 || core_id >= num_cores)
                 return EINVAL;
      
              cpu_set_t cpuset;
              CPU_ZERO(&cpuset);
              CPU_SET(core_id, &cpuset);
      
              pthread_t current_thread = pthread_self();
              return pthread_setaffinity_np(current_thread,
      sizeof(cpu_set_t), &cpuset);
      }
      
      static void *fn_thread (void *p_data)
      {
              int ret;
              pthread_t thread;
      
              stick_this_thread_to_core((int)p_data);
      
              while (1) {
                      sleep(1);
              }
      
              return NULL;
      }
      
      int main()
      {
              volatile unsigned char *p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
                                               MAP_SHARED | MAP_ANONYMOUS, -1, 0);
              pthread_t threads[4];
              int ret;
      
              for (int i = 0; i < 4; ++i) {
                      ret = pthread_create(&threads[i], NULL, fn_thread, (void *)i);
                      if (ret)
                      {
                              printf("%s", strerror (ret));
                      }
              }
      
              memset(p, 0x88, SIZE);
      
              for (int k = 0; k < 10000; k++) {
                      /* swap in */
                      for (int i = 0; i < SIZE; i += 4096) {
                              (void)p[i];
                      }
      
                      /* swap out */
                      madvise(p, SIZE, MADV_PAGEOUT);
              }
      
              for (int i = 0; i < 4; i++)
              {
                      pthread_cancel(threads[i]);
              }
      
              for (int i = 0; i < 4; i++)
              {
                      pthread_join(threads[i], NULL);
              }
      
              return 0;
      }
      Signed-off-by: default avatarAlexandre Ghiti <alexghiti@rivosinc.com>
      Reviewed-by: default avatarJisheng Zhang <jszhang@kernel.org>
      Tested-by: Jisheng Zhang <jszhang@kernel.org> # Tested on TH1520
      Tested-by: default avatarNam Cao <namcao@linutronix.de>
      Link: https://lore.kernel.org/r/20240108193640.344929-1-alexghiti@rivosinc.comSigned-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      54d7431a
    • Andrew Jones's avatar
      riscv: sbi: Introduce system suspend support · 4dc4af9c
      Andrew Jones authored
      When the SUSP SBI extension is present it implies that the standard
      "suspend to RAM" type is available. Wire it up to the generic
      platform suspend support, also applying the already present support
      for non-retentive CPU suspend. When the kernel is built with
      CONFIG_SUSPEND, one can do 'echo mem > /sys/power/state' to suspend.
      Resumption will occur when a platform-specific wake-up event arrives.
      Signed-off-by: default avatarAndrew Jones <ajones@ventanamicro.com>
      Tested-by: default avatarSamuel Holland <samuel.holland@sifive.com>
      Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Link: https://lore.kernel.org/r/20231206110807.35882-4-ajones@ventanamicro.comSigned-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      4dc4af9c
  23. 10 Jan, 2024 4 commits
  24. 30 Dec, 2023 1 commit
  25. 20 Dec, 2023 1 commit
    • Arnd Bergmann's avatar
      kexec: fix KEXEC_FILE dependencies · c1ad12ee
      Arnd Bergmann authored
      The cleanup for the CONFIG_KEXEC Kconfig logic accidentally changed the
      'depends on CRYPTO=y' dependency to a plain 'depends on CRYPTO', which
      causes a link failure when all the crypto support is in a loadable module
      and kexec_file support is built-in:
      
      x86_64-linux-ld: vmlinux.o: in function `__x64_sys_kexec_file_load':
      (.text+0x32e30a): undefined reference to `crypto_alloc_shash'
      x86_64-linux-ld: (.text+0x32e58e): undefined reference to `crypto_shash_update'
      x86_64-linux-ld: (.text+0x32e6ee): undefined reference to `crypto_shash_final'
      
      Both s390 and x86 have this problem, while ppc64 and riscv have the
      correct dependency already.  On riscv, the dependency is only used for the
      purgatory, not for the kexec_file code itself, which may be a bit
      surprising as it means that with CONFIG_CRYPTO=m, it is possible to enable
      KEXEC_FILE but then the purgatory code is silently left out.
      
      Move this into the common Kconfig.kexec file in a way that is correct
      everywhere, using the dependency on CRYPTO_SHA256=y only when the
      purgatory code is available.  This requires reversing the dependency
      between ARCH_SUPPORTS_KEXEC_PURGATORY and KEXEC_FILE, but the effect
      remains the same, other than making riscv behave like the other ones.
      
      On s390, there is an additional dependency on CRYPTO_SHA256_S390, which
      should technically not be required but gives better performance.  Remove
      this dependency here, noting that it was not present in the initial
      Kconfig code but was brought in without an explanation in commit
      71406883 ("s390/kexec_file: Add kexec_file_load system call").
      
      [arnd@arndb.de: fix riscv build]
        Link: https://lkml.kernel.org/r/67ddd260-d424-4229-a815-e3fcfb864a77@app.fastmail.com
      Link: https://lkml.kernel.org/r/20231023110308.1202042-1-arnd@kernel.org
      Fixes: 6af51380 ("x86/kexec: refactor for kernel/Kconfig.kexec")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarEric DeVolder <eric_devolder@yahoo.com>
      Tested-by: default avatarEric DeVolder <eric_devolder@yahoo.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Gordeev <agordeev@linux.ibm.com>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Conor Dooley <conor@kernel.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sven Schnelle <svens@linux.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c1ad12ee