Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1608902

Re: locking/atomic: Introduce atomic_try_cmpxchg()

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: locking/atomic: Introduce atomic_try_cmpxchg()
Date 2017-03-24 20:20 +0100
Message-ID <toCUG-63a-25@gated-at.bofh.it> (permalink)
References (1 earlier) <toyo1-2Pm-7@gated-at.bofh.it> <toAzw-4jh-17@gated-at.bofh.it> <toAJc-4pW-11@gated-at.bofh.it> <toBcd-4QJ-5@gated-at.bofh.it> <toCrE-5z0-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Mar 24, 2017 at 11:45 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> Is there some hack like if __builtin_is_unescaped(*val) *val = old;
> that would work?

See my recent email suggesting a completely different interface, which
avoids this problem.

My interface generates:

0000000000000000 <T_refcount_inc>:
   0: 8b 07                 mov    (%rdi),%eax
   2: 83 f8 ff             cmp    $0xffffffff,%eax
   5: 74 12                 je     19 <T_refcount_inc+0x19>
   7: 85 c0                 test   %eax,%eax
   9: 74 0a                 je     15 <T_refcount_inc+0x15>
   b: 8d 50 01             lea    0x1(%rax),%edx
   e: f0 0f b1 17           lock cmpxchg %edx,(%rdi)
  12: 75 ee                 jne    2 <T_refcount_inc+0x2>
  14: c3                   retq
  15: 31 c0                 xor    %eax,%eax
  17: 0f 0b                 ud2
  19: c3                   retq

for PeterZ's test-case, which seems optimal.

Of course, PeterZ used -Os, which isn't actually very natural for the
kernel. Using -O2 I get something else. It turns out that my macro
should use

        if (likely(__txchg_success)) goto success_label;

(that "likely()" is criticial) to make gcc not try to optimize for the
looping case.

So with that "likely()" fixed, with -O2 I get:

0000000000000000 <T_refcount_inc>:
   0: 8b 07                 mov    (%rdi),%eax
   2: 83 f8 ff             cmp    $0xffffffff,%eax
   5: 74 0d                 je     14 <T_refcount_inc+0x14>
   7: 85 c0                 test   %eax,%eax
   9: 74 12                 je     1d <T_refcount_inc+0x1d>
   b: 8d 50 01             lea    0x1(%rax),%edx
   e: f0 0f b1 17           lock cmpxchg %edx,(%rdi)
  12: 75 02                 jne    16 <T_refcount_inc+0x16>
  14: f3 c3                 repz retq
  16: 83 f8 ff             cmp    $0xffffffff,%eax
  19: 75 ec                 jne    7 <T_refcount_inc+0x7>
  1b: f3 c3                 repz retq
  1d: 31 c0                 xor    %eax,%eax
  1f: 0f 0b                 ud2
  21: c3                   retq

which again looks pretty optimal (it did indeed actually generate
bigger but potentially higher-performance code by making the good case
be a fallthrough, and the unlikely case be a _forward_ jump that will
be predicted not-taken in the absense of other rpediction information.

(Of course, this also depends on the exact behavior that PeterZ's code
had, namely an exception for use-after-free, but a silent saturation)

            Linus

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

re: locking/atomic: Introduce atomic_try_cmpxchg() Dmitry Vyukov <dvyukov@google.com> - 2017-03-24 13:50 +0100
  Re: locking/atomic: Introduce atomic_try_cmpxchg() Dmitry Vyukov <dvyukov@google.com> - 2017-03-24 15:30 +0100
  Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 15:30 +0100
    Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 17:50 +0100
      Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@amacapital.net> - 2017-03-24 18:00 +0100
        Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 18:30 +0100
          Re: locking/atomic: Introduce atomic_try_cmpxchg() Dmitry Vyukov <dvyukov@google.com> - 2017-03-24 19:00 +0100
            Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 19:20 +0100
              Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 19:20 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@kernel.org> - 2017-03-24 20:20 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-24 20:30 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@amacapital.net> - 2017-03-24 20:30 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 21:20 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 21:20 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@amacapital.net> - 2017-03-24 21:30 +0100
              Re: locking/atomic: Introduce atomic_try_cmpxchg() Dmitry Vyukov <dvyukov@google.com> - 2017-03-24 19:20 +0100
          Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 19:10 +0100
          Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 19:20 +0100
          Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@amacapital.net> - 2017-03-24 19:50 +0100
            Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-24 20:20 +0100
              Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 22:30 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-25 09:00 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-25 19:10 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-25 19:30 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-25 19:40 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-25 22:20 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-25 23:10 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-27 12:00 +0200
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-25 19:40 +0100
            Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 21:30 +0100
              Re: locking/atomic: Introduce atomic_try_cmpxchg() Andy Lutomirski <luto@kernel.org> - 2017-03-24 21:30 +0100
                Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 22:10 +0100
          Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-24 20:10 +0100
            Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-24 21:50 +0100
              Re: locking/atomic: Introduce atomic_try_cmpxchg() Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-24 22:00 +0100
  Re: locking/atomic: Introduce atomic_try_cmpxchg() Peter Zijlstra <peterz@infradead.org> - 2017-03-27 14:20 +0200
    Re: locking/atomic: Introduce atomic_try_cmpxchg() Dmitry Vyukov <dvyukov@google.com> - 2017-03-27 15:50 +0200

csiph-web