1. 03 Oct, 2018 1 commit
  2. 11 Aug, 2018 1 commit
  3. 24 Jul, 2018 2 commits
  4. 21 Jul, 2018 1 commit
  5. 18 Jul, 2018 1 commit
  6. 10 Jul, 2018 1 commit
  7. 09 Jul, 2018 1 commit
  8. 06 Jul, 2018 1 commit
  9. 05 Jul, 2018 1 commit
  10. 04 Jul, 2018 1 commit
  11. 28 Jun, 2018 1 commit
  12. 27 Jun, 2018 1 commit
  13. 23 Jun, 2018 1 commit
  14. 22 Jun, 2018 1 commit
  15. 19 Jun, 2018 2 commits
  16. 18 Jun, 2018 4 commits
  17. 15 Jun, 2018 6 commits
  18. 14 Jun, 2018 1 commit
    • Christoph Hellwig's avatar
      dma-mapping: move all DMA mapping code to kernel/dma · cf65a0f6
      Christoph Hellwig authored
      Currently the code is split over various files with dma- prefixes in the
      lib/ and drives/base directories, and the number of files keeps growing.
      Move them into a single directory to keep the code together and remove
      the file name prefixes.  To match the irq infrastructure this directory
      is placed under the kernel/ directory.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      cf65a0f6
  19. 11 Jun, 2018 1 commit
  20. 10 Jun, 2018 1 commit
  21. 08 Jun, 2018 3 commits
  22. 06 Jun, 2018 2 commits
    • Mathieu Desnoyers's avatar
      rseq/selftests: Provide Makefile, scripts, gitignore · ccba8b64
      Mathieu Desnoyers authored
      A run_param_test.sh script runs many variants of the parametrizable
      tests.
      
      Wire up the rseq Makefile, add directory entry into MAINTAINERS file.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: linux-kselftest@vger.kernel.org
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Chris Lameter <cl@linux.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ben Maurer <bmaurer@fb.com>
      Cc: linux-api@vger.kernel.org
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: https://lkml.kernel.org/r/20180602124408.8430-17-mathieu.desnoyers@efficios.com
      ccba8b64
    • Mathieu Desnoyers's avatar
      rseq: Introduce restartable sequences system call · d7822b1e
      Mathieu Desnoyers authored
      Expose a new system call allowing each thread to register one userspace
      memory area to be used as an ABI between kernel and user-space for two
      purposes: user-space restartable sequences and quick access to read the
      current CPU number value from user-space.
      
      * Restartable sequences (per-cpu atomics)
      
      Restartables sequences allow user-space to perform update operations on
      per-cpu data without requiring heavy-weight atomic operations.
      
      The restartable critical sections (percpu atomics) work has been started
      by Paul Turner and Andrew Hunter. It lets the kernel handle restart of
      critical sections. [1] [2] The re-implementation proposed here brings a
      few simplifications to the ABI which facilitates porting to other
      architectures and speeds up the user-space fast path.
      
      Here are benchmarks of various rseq use-cases.
      
      Test hardware:
      
      arm32: ARMv7 Processor rev 4 (v7l) "Cubietruck", 2-core
      x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
      
      The following benchmarks were all performed on a single thread.
      
      * Per-CPU statistic counter increment
      
                      getcpu+atomic (ns/op)    rseq (ns/op)    speedup
      arm32:                344.0                 31.4          11.0
      x86-64:                15.3                  2.0           7.7
      
      * LTTng-UST: write event 32-bit header, 32-bit payload into tracer
                   per-cpu buffer
      
                      getcpu+atomic (ns/op)    rseq (ns/op)    speedup
      arm32:               2502.0                 2250.0         1.1
      x86-64:               117.4                   98.0         1.2
      
      * liburcu percpu: lock-unlock pair, dereference, read/compare word
      
                      getcpu+atomic (ns/op)    rseq (ns/op)    speedup
      arm32:                751.0                 128.5          5.8
      x86-64:                53.4                  28.6          1.9
      
      * jemalloc memory allocator adapted to use rseq
      
      Using rseq with per-cpu memory pools in jemalloc at Facebook (based on
      rseq 2016 implementation):
      
      The production workload response-time has 1-2% gain avg. latency, and
      the P99 overall latency drops by 2-3%.
      
      * Reading the current CPU number
      
      Speeding up reading the current CPU number on which the caller thread is
      running is done by keeping the current CPU number up do date within the
      cpu_id field of the memory area registered by the thread. This is done
      by making scheduler preemption set the TIF_NOTIFY_RESUME flag on the
      current thread. Upon return to user-space, a notify-resume handler
      updates the current CPU value within the registered user-space memory
      area. User-space can then read the current CPU number directly from
      memory.
      
      Keeping the current cpu id in a memory area shared between kernel and
      user-space is an improvement over current mechanisms available to read
      the current CPU number, which has the following benefits over
      alternative approaches:
      
      - 35x speedup on ARM vs system call through glibc
      - 20x speedup on x86 compared to calling glibc, which calls vdso
        executing a "lsl" instruction,
      - 14x speedup on x86 compared to inlined "lsl" instruction,
      - Unlike vdso approaches, this cpu_id value can be read from an inline
        assembly, which makes it a useful building block for restartable
        sequences.
      - The approach of reading the cpu id through memory mapping shared
        between kernel and user-space is portable (e.g. ARM), which is not the
        case for the lsl-based x86 vdso.
      
      On x86, yet another possible approach would be to use the gs segment
      selector to point to user-space per-cpu data. This approach performs
      similarly to the cpu id cache, but it has two disadvantages: it is
      not portable, and it is incompatible with existing applications already
      using the gs segment selector for other purposes.
      
      Benchmarking various approaches for reading the current CPU number:
      
      ARMv7 Processor rev 4 (v7l)
      Machine model: Cubietruck
      - Baseline (empty loop):                                    8.4 ns
      - Read CPU from rseq cpu_id:                               16.7 ns
      - Read CPU from rseq cpu_id (lazy register):               19.8 ns
      - glibc 2.19-0ubuntu6.6 getcpu:                           301.8 ns
      - getcpu system call:                                     234.9 ns
      
      x86-64 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz:
      - Baseline (empty loop):                                    0.8 ns
      - Read CPU from rseq cpu_id:                                0.8 ns
      - Read CPU from rseq cpu_id (lazy register):                0.8 ns
      - Read using gs segment selector:                           0.8 ns
      - "lsl" inline assembly:                                   13.0 ns
      - glibc 2.19-0ubuntu6 getcpu:                              16.6 ns
      - getcpu system call:                                      53.9 ns
      
      - Speed (benchmark taken on v8 of patchset)
      
      Running 10 runs of hackbench -l 100000 seems to indicate, contrary to
      expectations, that enabling CONFIG_RSEQ slightly accelerates the
      scheduler:
      
      Configuration: 2 sockets * 8-core Intel(R) Xeon(R) CPU E5-2630 v3 @
      2.40GHz (directly on hardware, hyperthreading disabled in BIOS, energy
      saving disabled in BIOS, turboboost disabled in BIOS, cpuidle.off=1
      kernel parameter), with a Linux v4.6 defconfig+localyesconfig,
      restartable sequences series applied.
      
      * CONFIG_RSEQ=n
      
      avg.:      41.37 s
      std.dev.:   0.36 s
      
      * CONFIG_RSEQ=y
      
      avg.:      40.46 s
      std.dev.:   0.33 s
      
      - Size
      
      On x86-64, between CONFIG_RSEQ=n/y, the text size increase of vmlinux is
      567 bytes, and the data size increase of vmlinux is 5696 bytes.
      
      [1] https://lwn.net/Articles/650333/
      [2] http://www.linuxplumbersconf.org/2013/ocw/system/presentations/1695/original/LPC%20-%20PerCpu%20Atomics.pdfSigned-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Chris Lameter <cl@linux.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ben Maurer <bmaurer@fb.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com
      Link: http://lkml.kernel.org/r/20150624222609.6116.86035.stgit@kitami.mtv.corp.google.com
      Link: https://lkml.kernel.org/r/20180602124408.8430-3-mathieu.desnoyers@efficios.com
      d7822b1e
  23. 05 Jun, 2018 2 commits
    • Greg Kroah-Hartman's avatar
      staging: lustre: delete the filesystem from the tree. · be65f9ed
      Greg Kroah-Hartman authored
      The Lustre filesystem has been in the kernel tree for over 5 years now.
      While it has been an endless source of enjoyment for new kernel
      developers learning how to do basic codingstyle cleanups, as well as an
      semi-entertaining source of bewilderment from the vfs developers any
      time they have looked into the codebase to try to figure out how to port
      their latest api changes to this filesystem, it has not really moved
      forward into the "this is in shape to get out of staging" despite many
      half-completed attempts.
      
      And getting code out of staging is the main goal of that portion of the
      kernel tree.  Code should not stagnate and it feels like having this
      code in staging is only causing the development cycle of the filesystem
      to take longer than it should.  There is a whole separate out-of-tree
      copy of this codebase where the developers work on it, and then random
      changes are thrown over the wall at staging at some later point in time.
      This dual-tree development model has never worked, and the state of this
      codebase is proof of that.
      
      So, let's just delete the whole mess.  Now the lustre developers can go
      off and work in their out-of-tree codebase and not have to worry about
      providing valid changelog entries and breaking their patches up into
      logical pieces.  They can take the time they have spend doing those
      types of housekeeping chores and get the codebase into a much better
      shape, and it can be submitted for inclusion into the real part of the
      kernel tree when ready.
      
      Cc: Oleg Drokin <oleg.drokin@intel.com>
      Cc: Andreas Dilger <andreas.dilger@intel.com>
      Cc: James Simmons <jsimmons@infradead.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be65f9ed
    • Josh Poimboeuf's avatar
      MAINTAINERS: add Josh Poimboeuf as faddr2line maintainer · 2562c011
      Josh Poimboeuf authored
      ... so I finally get credit for my greatest accomplishment.
      
      And, less importantly, so get_maintainer.pl will actually CC me on
      future patches.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2562c011
  24. 04 Jun, 2018 3 commits
    • Palmer Dabbelt's avatar
      MAINTAINERS: Update Albert's email, he's back at Berkeley · 9c521764
      Palmer Dabbelt authored
      When I was adding a MAINTAINERS entry for SiFive's drivers I realized
      that Albert's email is out of date -- he's gone back to Berkeley, so his
      SiFive email is technically defunct.  This patch updates his entry to a
      current email address, hosted at Berkeley.
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      9c521764
    • Palmer Dabbelt's avatar
      MAINTAINERS: Add myself as a maintainer for SiFive's drivers · 3ed45d7f
      Palmer Dabbelt authored
      There aren't actually any files in the tree that match these patterns
      right now, but we've just started submitting our drivers so I thought it
      would be good to make sure there's at least someone at SiFive who's
      listed as maintaining them.  I'm leaving the RISC-V lists on here
      because:
      
      * As of today, all the RISC-V ASICs that people can actually buy are
        from SiFive -- though hopefully there'll be more soon!
      * The RTL for many of our devices is open source, so I anticipate these
        devices might make they way chips from other vendors.
      * We may standardize some of these devices as part of a RISC-V
        specification at some point in the future.
      
      I'm a bit swamped right now so I might not be the most active maintainer
      of these drivers, but I think it'd be good to make sure someone who has
      hardware access gets CC'd on updates to our drivers just as a sanity
      check.  Hopefully that's an OK way to handle this.
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      3ed45d7f
    • Jeff Kirsher's avatar
      Documentation: e1000: Update kernel documentation · 228046e7
      Jeff Kirsher authored
      Updated the e1000.txt kernel documentation with the latest information.
      
      Also convert the text file to reStructuredText (RST) format, since the
      Linux kernel documentation now uses this format for documentation.
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      228046e7