1. 30 1月, 2018 1 次提交
  2. 10 11月, 2017 1 次提交
    • M
      locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE · 450cbdd0
      Michael S. Tsirkin 提交于
      MFENCE appears to be way slower than a locked instruction - let's use
      LOCK ADD unconditionally, as we always did on old 32-bit.
      
      Performance testing results:
      
        perf stat -r 10 -- ./virtio_ring_0_9 --sleep --host-affinity 0 --guest-affinity 0
        Before:
               0.922565990 seconds time elapsed                                          ( +-  1.15% )
        After:
               0.578667024 seconds time elapsed                                          ( +-  1.21% )
      
      i.e. about ~60% faster.
      
      Just poking at SP would be the most natural, but if we then read the
      value from SP, we get a false dependency which will slow us down.
      
      This was noted in this article:
      
        http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
      
      And is easy to reproduce by sticking a barrier in a small non-inline
      function.
      
      So let's use a negative offset - which avoids this problem since we
      build with the red zone disabled.
      
      For userspace, use an address just below the redzone.
      
      The one difference between LOCK ADD and MFENCE is that LOCK ADD does
      not affect CLFLUSH, previous patches converted all uses of CLFLUSH to
      call mb(), such that changes to smp_mb() won't affect it.
      
      Update mb/rmb/wmb() on 32-bit to use the negative offset, too, for
      consistency.
      
      As a follow-up, it might be worth considering switching users
      of CLFLUSH to another API (e.g. clflush_mb()?) - we will
      then be able to convert mb() to smp_mb() again.
      
      Also arguably, GCC should switch to use LOCK ADD for __sync_synchronize().
      This might be worth pursuing separately.
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: qemu-devel@nongnu.org
      Cc: virtualization@lists.linux-foundation.org
      Link: http://lkml.kernel.org/r/1509118355-4890-1-git-send-email-mst@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      450cbdd0
  3. 09 5月, 2017 1 次提交
  4. 20 1月, 2017 1 次提交
  5. 31 10月, 2016 1 次提交
  6. 26 1月, 2016 1 次提交
    • M
      tools/virtio: add ringtest utilities · 481eaec3
      Michael S. Tsirkin 提交于
      This adds micro-benchmarks useful for tuning virtio ring layouts.
      Three layouts are currently implemented:
      
      - virtio 0.9 compatible one
      - an experimental extension bypassing the ring index, polling ring
        itself instead
      - an experimental extension bypassing avail and used ring completely
      
      Typical use:
      
      sh run-on-all.sh perf stat -r 10 --log-fd 1 -- ./ring
      
      It doesn't depend on the kernel directly, but it's handy
      to have as much virtio stuff as possible in one tree.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      481eaec3