All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end()
Date: Fri, 27 Mar 2020 02:42:27 +0000	[thread overview]
Message-ID: <20200327024227.GT23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHk-=whnTRF5yA2MrPGcmMm=hXaGHfC2HEDtNzA=_1=szhJ4-w@mail.gmail.com>

On Tue, Mar 24, 2020 at 01:57:19PM -0700, Linus Torvalds wrote:
> On Tue, Mar 24, 2020 at 1:45 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > OK...  BTW, I'd been trying to recall the reasons for the way
> > __futex_atomic_op2() loop is done; ISTR some discussion along
> > the lines of cacheline ping-pong prevention, but I'd been unable
> > to reconstruct enough details to find it and I'm not sure it
> > hadn't been about some other code ;-/
> 
> No, that doesn't look like any cacheline advantage I can think of -
> quite the reverse.
> 
> I suspect it's just lazy code, with the reload being unnecessary. Or
> it might be written that way because you avoid an extra variable.
> 
> In fact, from a cacheline optimization standpoint, there are
> advantages to not doing the load even on the initial run: if you know
> a certain value is particularly likely, there are advantages to just
> _assuming_ that value, rather than loading it. So no initial load at
> all, and just initialize the first value to the likely case.
> 
> That can avoid an unnecessary "load for shared ownership" cacheline
> state transition (since the cmpxchg will want to turn it into an
> exclusive modified cacheline anyway).
> 
> But I don't think that optimization is likely the case here, and
> you're right, the loop would be better written with the initial load
> outside the loop.

OK, updated branch is in the same place; changes: __futex_atomic_op{1,2}
turned into unsafe_atomic_op{1,2}, with "goto on error" folded into those.
And pointless reload removed from cmpxchg loop in unsafe_atomic_op2().
Diffstat:
 arch/alpha/include/asm/futex.h      |  5 +-
 arch/arc/include/asm/futex.h        |  5 +-
 arch/arm/include/asm/futex.h        |  5 +-
 arch/arm64/include/asm/futex.h      |  5 +-
 arch/hexagon/include/asm/futex.h    |  5 +-
 arch/ia64/include/asm/futex.h       |  5 +-
 arch/microblaze/include/asm/futex.h |  5 +-
 arch/mips/include/asm/futex.h       |  5 +-
 arch/nds32/include/asm/futex.h      |  6 +--
 arch/openrisc/include/asm/futex.h   |  5 +-
 arch/parisc/include/asm/futex.h     |  2 -
 arch/powerpc/include/asm/futex.h    |  5 +-
 arch/riscv/include/asm/futex.h      |  5 +-
 arch/s390/include/asm/futex.h       |  2 -
 arch/sh/include/asm/futex.h         |  4 --
 arch/sparc/include/asm/futex_64.h   |  4 --
 arch/x86/include/asm/futex.h        | 97 ++++++++++++++++++++++++-------------
 arch/x86/include/asm/uaccess.h      | 93 -----------------------------------
 arch/xtensa/include/asm/futex.h     |  5 +-
 include/asm-generic/futex.h         |  2 -
 kernel/futex.c                      |  5 +-
 tools/objtool/check.c               |  1 +
 22 files changed, 93 insertions(+), 183 deletions(-)

Sorry about the fuckup when sending that patchset ;-/  It ended up cc'd to
x86 list instead of the futex one; Message-Id of the beginning of the
thread is <20200327022836.881203-1-viro@ZenIV.linux.org.uk>.

  reply	other threads:[~2020-03-27  2:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 18:50 [RFC][PATCHSET] futex uaccess cleanups Al Viro
2020-03-23 18:51 ` [RFC][PATCH 1/7] futex: arch_futex_atomic_op_inuser() calling conventions change Al Viro
2020-03-23 18:51   ` [RFC][PATCH 2/7] sh: no need of access_ok() in arch_futex_atomic_op_inuser() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 3/7] [parisc, s390, sparc64] no need for access_ok() in futex handling Al Viro
2020-03-23 18:51   ` [RFC][PATCH 4/7] objtool: whitelist __sanitizer_cov_trace_switch() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end() Al Viro
2020-03-23 19:06     ` Linus Torvalds
2020-03-24  2:08       ` Al Viro
2020-03-24 16:19         ` Linus Torvalds
2020-03-24 20:42           ` Al Viro
2020-03-24 20:57             ` Linus Torvalds
2020-03-27  2:42               ` Al Viro [this message]
2020-03-27  3:42                 ` Linus Torvalds
2020-03-27  3:49                   ` Linus Torvalds
2020-03-27  4:03                     ` Linus Torvalds
2020-03-27  4:35                       ` Josh Poimboeuf
2020-03-23 18:51   ` [RFC][PATCH 6/7] generic arch_futex_atomic_op_inuser() doesn't need access_ok() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 7/7] x86: get rid of user_atomic_cmpxchg_inatomic() Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200327024227.GT23230@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.