mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: benh@kernel.crashing.org,
	xen-devel <xen-devel@lists.xensource.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	kvm-devel <kvm-devel@lists.sourceforge.net>,
	x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Virtualization Mailing List <virtualization@lists.osdl.org>,
	Hugh Dickins <hugh@veritas.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction
Date: Wed, 18 Jun 2008 21:03:26 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0806182050470.2907@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0806181743390.2907@woody.linux-foundation.org>



On Wed, 18 Jun 2008, Linus Torvalds wrote:
> 
> And yes, the "lock andl" should be noticeably faster than the xchgl.

I dunno. Here's a untested (!!) patch that turns constant-bit 
set/clear_bit ops into byte mask ops (lock orb/andb).

It's not exactly pretty. The reason for using the byte versions is that a 
locked op is serialized in the memory pipeline anyway, so there are no 
forwarding issues (that could slow down things when we access things with 
different sizes), and the byte ops are a lot smaller than 32-bit and 
particularly 64-bit ops (big constants, and the 64-bit ops need the REX 
prefix byte too).

[ Side note: I wonder if we should turn the "test_bit()" C version into a 
  "char *" version too.. It could actually help with alias analysis, since 
  char pointers can alias anything. So it might be the RightThing(tm) to 
  do for multiple reasons. I dunno. It's a separate issue. ]

It does actually shrink the kernel image a bit (a couple of hundred bytes 
on the text segment for my everything-compiled-in image), and while it's 
totally untested the (admittedly few) code generation points I looked at 
seemed sane. And "lock orb" should be noticeably faster than "lock bts".

If somebody wants to play with it, go wild. I didn't do "change_bit()", 
because nobody sane uses that thing anyway. I guarantee nothing. And if it 
breaks, nobody saw me do anything.  You can't prove this email wasn't sent 
by somebody who is good at forging smtp.

This does require a gcc that is recent enough for "__builtin_constant_p()" 
to work in an inline function, but I suspect our kernel requirements are 
already higher than that. And if you do have an old gcc that is supported, 
the worst that would happen is that the optimization doesn't trigger.

		Linus

---
 include/asm-x86/bitops.h |   27 ++++++++++++++++++++++-----
 1 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/include/asm-x86/bitops.h b/include/asm-x86/bitops.h
index ee4b3ea..c1b7f91 100644
--- a/include/asm-x86/bitops.h
+++ b/include/asm-x86/bitops.h
@@ -23,11 +23,22 @@
 #if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 1)
 /* Technically wrong, but this avoids compilation errors on some gcc
    versions. */
-#define ADDR "=m" (*(volatile long *) addr)
+#define BITOP_ADDR(x) "=m" (*(volatile long *) (x))
 #else
-#define ADDR "+m" (*(volatile long *) addr)
+#define BITOP_ADDR(x) "+m" (*(volatile long *) (x))
 #endif
 
+#define ADDR BITOP_ADDR(addr)
+
+/*
+ * We do the locked ops that don't return the old value as
+ * a mask operation on a byte.
+ */
+#define IS_IMMEDIATE(nr) \
+	(__builtin_constant_p(nr))
+#define CONST_MASK_ADDR BITOP_ADDR(addr + (nr>>3))
+#define CONST_MASK (1 << (nr & 7))
+
 /**
  * set_bit - Atomically set a bit in memory
  * @nr: the bit to set
@@ -43,9 +54,12 @@
  * Note that @nr may be almost arbitrarily large; this function is not
  * restricted to acting on a single-word quantity.
  */
-static inline void set_bit(int nr, volatile void *addr)
+static inline void set_bit(unsigned int nr, volatile void *addr)
 {
-	asm volatile(LOCK_PREFIX "bts %1,%0" : ADDR : "Ir" (nr) : "memory");
+	if (IS_IMMEDIATE(nr))
+		asm volatile(LOCK_PREFIX "orb %1,%0" : CONST_MASK_ADDR : "i" (CONST_MASK) : "memory");
+	else
+		asm volatile(LOCK_PREFIX "bts %1,%0" : ADDR : "Ir" (nr) : "memory");
 }
 
 /**
@@ -74,7 +88,10 @@ static inline void __set_bit(int nr, volatile void *addr)
  */
 static inline void clear_bit(int nr, volatile void *addr)
 {
-	asm volatile(LOCK_PREFIX "btr %1,%0" : ADDR : "Ir" (nr));
+	if (IS_IMMEDIATE(nr))
+		asm volatile(LOCK_PREFIX "andb %1,%0" : CONST_MASK_ADDR : "i" (~CONST_MASK));
+	else
+		asm volatile(LOCK_PREFIX "btr %1,%0" : ADDR : "Ir" (nr));
 }
 
 /*

  reply	other threads:[~2008-06-19  4:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16 11:29 [PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2) Jeremy Fitzhardinge
2008-06-16 11:30 ` [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction Jeremy Fitzhardinge
2008-06-16 17:29   ` Linus Torvalds
2008-06-16 18:13     ` Hugh Dickins
2008-06-16 18:49       ` Ingo Molnar
2008-06-18 23:23   ` Benjamin Herrenschmidt
2008-06-18 23:59     ` Jeremy Fitzhardinge
2008-06-19  0:15       ` Jeremy Fitzhardinge
2008-06-19  0:24         ` Linus Torvalds
2008-06-19  0:37           ` Jeremy Fitzhardinge
2008-06-19  0:49             ` Linus Torvalds
2008-06-19  4:03               ` Linus Torvalds [this message]
2008-06-19 11:58                 ` Ingo Molnar
2008-06-19 12:03                   ` Ingo Molnar
2008-06-19 12:20                   ` Akinobu Mita
2008-06-19 16:30                   ` Linus Torvalds
2008-06-19 16:47                     ` Ingo Molnar
2008-06-20 10:10                       ` Ingo Molnar
2008-06-20 19:06                         ` Jeremy Fitzhardinge
2008-06-20 19:15                           ` Linus Torvalds
2008-06-20 19:56                             ` Ingo Molnar
2008-06-20 20:03                               ` Linus Torvalds
2008-06-20 20:16                                 ` Jeremy Fitzhardinge
2008-06-20 20:22                                   ` Jeremy Fitzhardinge
2008-06-21  6:06                                     ` Ingo Molnar
2008-06-20 20:05                               ` Jeremy Fitzhardinge
2008-06-19  0:39           ` Benjamin Herrenschmidt
2008-06-19  5:03             ` Jeremy Fitzhardinge
2008-06-19  7:20               ` Benjamin Herrenschmidt
2008-06-19 17:57                 ` Jeremy Fitzhardinge
2008-06-16 11:30 ` [PATCH 2 of 4] paravirt: add hooks for ptep_modify_prot_start/commit Jeremy Fitzhardinge
2008-06-16 11:30 ` [PATCH 3 of 4] xen: implement ptep_modify_prot_start/commit Jeremy Fitzhardinge
2008-06-16 11:30 ` [PATCH 4 of 4] xen: add mechanism to extend existing multicalls Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2008-05-31  0:04 [PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2) Jeremy Fitzhardinge
2008-05-31  0:04 ` [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction Jeremy Fitzhardinge
2008-06-02 11:13   ` Ingo Molnar
2008-06-02 11:57     ` Jeremy Fitzhardinge

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=alpine.LFD.1.10.0806182050470.2907@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=benh@kernel.crashing.org \
    --cc=hugh@veritas.com \
    --cc=jeremy@goop.org \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.osdl.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome