From: Andrew Morton <akpm@osdl.org>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, torvalds@osdl.org
Subject: Re: [patch] i386 spinlocks: disable interrupts only if we enabled them
Date: Tue, 7 Mar 2006 16:15:50 -0800 [thread overview]
Message-ID: <20060307161550.27941df5.akpm@osdl.org> (raw)
In-Reply-To: <200603071837_MC3-1-BA13-E5FB@compuserve.com>
Chuck Ebbert <76306.1226@compuserve.com> wrote:
>
> _raw_spin_lock_flags() is entered with interrupts disabled. If it
> cannot obtain a spinlock, it checks the flags that were passed and
> re-enables interrupts before spinning if that's how the flags are set.
> When the spinlock might be available, it disables interrupts (even if
> they are already disabled) before trying to get the lock. Change that
> so interrupts are only disabled if they have been enabled. This costs
> nine bytes of duplicated spinloop code.
>
> Fastpath before patch:
> jle <keep looping> not-taken conditional jump
> cli disable interrupts
> jmp <try for lock> unconditional jump
>
> Fastpath after patch, if interrupts were not enabled:
> jg <try for lock> taken conditional branch
>
Well no. The fastpath is:
jns 4f we got the lock.
>
> --- 2.6.16-rc5-d2.orig/include/asm-i386/spinlock.h
> +++ 2.6.16-rc5-d2/include/asm-i386/spinlock.h
> @@ -35,18 +35,23 @@
> #define __raw_spin_lock_string_flags \
> "\n1:\t" \
> "lock ; decb %0\n\t" \
> - "jns 4f\n\t" \
> + "jns 5f\n" \
> "2:\t" \
> "testl $0x200, %1\n\t" \
> - "jz 3f\n\t" \
> - "sti\n\t" \
> + "jz 4f\n\t" \
> + "sti\n" \
> "3:\t" \
> "rep;nop\n\t" \
> "cmpb $0, %0\n\t" \
> "jle 3b\n\t" \
> "cli\n\t" \
> "jmp 1b\n" \
> - "4:\n\t"
> + "4:\t" \
> + "rep;nop\n\t" \
> + "cmpb $0, %0\n\t" \
> + "jg 1b\n\t" \
> + "jmp 4b\n" \
> + "5:\n\t"
>
So this is speeding up the slowpath, which really shouldn't matter unless
we have bigger problems.
And it's increasing text size. Which wouldn't be a big problem if the
spinning code was still in an out-of-line section, but it isn't any more.
(I forget why we undid that optimisation. What was wrong with it?)
next prev parent reply other threads:[~2006-03-08 0:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-07 23:34 Chuck Ebbert
2006-03-08 0:15 ` Andrew Morton [this message]
2006-03-08 0:43 ` Ingo Molnar
2006-03-08 2:52 ` Benjamin LaHaise
2006-03-08 6:55 ` Andrew Morton
2006-03-08 8:52 ` Nick Piggin
2006-03-08 1:45 Chuck Ebbert
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=20060307161550.27941df5.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=76306.1226@compuserve.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome