mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Mark Zealey <mark@zealos.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question and patch about spinlocks (x86)
Date: Thu, 11 Oct 2001 16:01:35 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.40.0110111555170.968-100000@blue1.dev.mcafeelabs.com> (raw)
In-Reply-To: <20011011213655.D7138@itsolve.co.uk>

On Thu, 11 Oct 2001, Mark Zealey wrote:

> Just looking through at the spinlock assembly I noticed a few things which I
> think are bugs:
>
>  	"js 2f\n" \
>  	".section .text.lock,\"ax\"\n" \
>  	"2:\t" \
> 	"cmpb $0,%0\n\t" \
>  	"rep;nop\n\t" \
> 	"jle 2b\n\t" \
>  	"jmp 1b\n" \
>  	".previous"
>
> We do the cmp loop as a 'soft' check, as the lock operand locks the whole system
> bus, stopping the system for a while (as much as 70 cycles, I believe). However,
> I don't understand why it was put before the 'rep; nop' which just sets the
> processor to wait for a bit. Surely it would be better to test *after* we have
> waited, as then we have a better chance of it being correct.

The effect of the rep-nop is not to wait but to slow down the cpu to the
speed of the memory bus.
This to not overload ( due pipeline prefetch ) the memory controller with
requests that 1) will be useless coz the watched memory location can
change only at the membus speed 2) will have a big cost on loop exit due
the invalidation of a number>1 requests issued on the memory controller.
Beside this i kindly agree to move the pause before the cmp.
There should be a valid reason to not have followed the intel scheme but i
don't know why.



- Davide



      reply	other threads:[~2001-10-11 22:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-11 20:36 Mark Zealey
2001-10-11 23:01 ` Davide Libenzi [this message]

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=Pine.LNX.4.40.0110111555170.968-100000@blue1.dev.mcafeelabs.com \
    --to=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@zealos.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

all inboxes | Powered by JetHome®