mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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?)

  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