From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, arjan@infradead.org, dada1@cosmosbay.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 spinlocks should use the full 32 bits, not only 8 bits
Date: Fri, 21 Oct 2005 01:26:58 +0200 [thread overview]
Message-ID: <20051020232658.GA29923@elte.hu> (raw)
In-Reply-To: <20051020160115.2b34cb8e.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> > > spin_lock is still uninlined.
> >
> > yes, and that should stay so i believe, for text size reasons. The BTB
> > should eliminate most effects of the call+ret itself.
>
> The old
>
> lock; decb
> js <different section>
> ...
>
> was pretty good.
yes, but that's 4-7+6==10-13 bytes of inline footprint, compared to
fixed 5 bytes. That gives quite some icache footprint with thousands of
call sites.
> > hm, with my patch, write_unlock should be inlined too.
>
> So it is. foo_unlock_irq() isn't though.
yes, that one should probably be inlined too, it's just 1 byte longer,
still the network-effects on register allocations give a net win:
text data bss dec hex filename
4072031 858208 387196 5317435 51233b vmlinux-smp-uninlined
4060671 858212 387196 5306079 50f6df vmlinux-smp-inlined
4058543 858212 387196 5303951 50ee8f vmlinux-irqop-inlined-too
another 0.05% drop in text size. Add-on patch below, it is against -rc5
plus prev_spinlock_patch. Boot-tested on 4-way x86 SMP. The box crashed
and burned. Joking.
Ingo
include/linux/spinlock.h | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
Index: linux/include/linux/spinlock.h
===================================================================
--- linux.orig/include/linux/spinlock.h
+++ linux/include/linux/spinlock.h
@@ -184,19 +184,29 @@ extern int __lockfunc generic__raw_read_
# define write_unlock(lock) __raw_write_unlock(&(lock)->raw_lock)
#endif
+#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT)
+# define spin_unlock_irq(lock) _spin_unlock_irq(lock)
+# define read_unlock_irq(lock) _read_unlock_irq(lock)
+# define write_unlock_irq(lock) _write_unlock_irq(lock)
+#else
+# define spin_unlock_irq(lock) \
+ do { __raw_spin_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
+# define read_unlock_irq(lock) \
+ do { __raw_read_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
+# define write_unlock_irq(lock) \
+ do { __raw_write_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
+#endif
+
#define spin_unlock_irqrestore(lock, flags) \
_spin_unlock_irqrestore(lock, flags)
-#define spin_unlock_irq(lock) _spin_unlock_irq(lock)
#define spin_unlock_bh(lock) _spin_unlock_bh(lock)
#define read_unlock_irqrestore(lock, flags) \
_read_unlock_irqrestore(lock, flags)
-#define read_unlock_irq(lock) _read_unlock_irq(lock)
#define read_unlock_bh(lock) _read_unlock_bh(lock)
#define write_unlock_irqrestore(lock, flags) \
_write_unlock_irqrestore(lock, flags)
-#define write_unlock_irq(lock) _write_unlock_irq(lock)
#define write_unlock_bh(lock) _write_unlock_bh(lock)
#define spin_trylock_bh(lock) __cond_lock(_spin_trylock_bh(lock))
next prev parent reply other threads:[~2005-10-20 23:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-11 4:04 i386 spinlock fairness: bizarre test results Chuck Ebbert
2005-10-11 9:42 ` Eric Dumazet
2005-10-11 13:00 ` Alan Cox
2005-10-11 14:44 ` Linus Torvalds
2005-10-11 15:32 ` [PATCH] i386 spinlocks should use the full 32 bits, not only 8 bits Eric Dumazet
2005-10-11 16:03 ` Linus Torvalds
2005-10-11 16:36 ` Eric Dumazet
2005-10-11 16:54 ` Linus Torvalds
2005-10-11 16:55 ` Linus Torvalds
2005-10-17 7:03 ` Andrew Morton
2005-10-17 7:20 ` Arjan van de Ven
2005-10-20 21:50 ` Ingo Molnar
2005-10-20 21:57 ` Linus Torvalds
2005-10-20 22:02 ` Ingo Molnar
2005-10-20 22:15 ` Linus Torvalds
2005-10-20 22:27 ` Ingo Molnar
2005-10-20 22:44 ` Andrew Morton
2005-10-20 22:53 ` Ingo Molnar
2005-10-20 23:01 ` Andrew Morton
2005-10-20 23:26 ` Ingo Molnar [this message]
2005-10-27 16:54 ` Paul Jackson
2005-10-11 17:59 ` Andi Kleen
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=20051020232658.GA29923@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.