linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Blanchard <anton@samba.org>
To: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>
Cc: linuxppc-dev@lists.linuxppc.org,
	yellowdog-devel@lists.terrasoftsolutions.com
Subject: Re: why isync in atomic icc and return and atomic dec and return for CONFIG_SMP
Date: Sun, 28 Jul 2002 12:26:56 +1000	[thread overview]
Message-ID: <20020728022655.GA19087@krispykreme> (raw)
In-Reply-To: <200207240804.36472.kevin.hendricks@sympatico.ca>


> So the atomic increment and decrement awith return are being used  in locks
> to protect extended criticial regions?

Yes, and so are test_and_set_bit etc. In fact I just found a bug in 2.5
where we were using bitops as spinlocks and were missing a memory
barrier on the lock drop (notice how clear_bit doesnt have a barrier and
we have smp_mb__before_clear_bit()).

> If so, a lock (of any sort) does require an isync (according to the manual)
> immediately after gaining the lock to make sure all speculative
> prefetching of instructions and data (possibly stale since someone else
> could have changed them before dropping the lock) should be done for pboth
> cases.

Yes.

> Why doesn't the same problem happen from the processor's speculative
> prefetching of instructions in the uniprocessor case?  Since that routine
> is inlined, the single processor could have loaded and started to process
> instructions past the "lock" before it actually aaquires the lock.

The big difference here is that there are no other cpus that can modify
memory. The cpu is free to prefetch the load but it must present
everything in program order to the program. Imagine what would happen if
we had int i = 0; i++; printf("%d\n", i); and we got 0 :)

There are two cases:

1. The prefetched load ends up conflicting with a previous store. The
load and all instructions after it depending on this load must be
flushed and retried.

2. The load has no previous dependencies. Since no other CPU could
modify memory then the prefetch is valid.

On a UP build the spinlocks disappear, all that is left is the interrupt
disable/enable if using the _irq and _irqsave versions. Having said this
you may ask we we need the the lwarx/stcwx. in the atomics and bitops at
all in a UP build. The reason is that we could get an interrupt and we
need to ensure that we are atomic wrt them.

BTW inlining isnt enough to avoid prefetching, the cpu is free to
prefetch both into a function and out of it.

Anton

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-07-28  2:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-23 21:25 why isync in atomic icc and return and atomic dec and return for CONFIG_SMP Kevin B. Hendricks
2002-07-23 22:15 ` Kevin B. Hendricks
2002-07-24  0:30 ` Anton Blanchard
2002-07-24 12:04   ` Kevin B. Hendricks
2002-07-28  2:26     ` Anton Blanchard [this message]
2002-08-03 14:28       ` Kevin B. Hendricks
2002-08-04 14:26         ` Michael R. Zucca

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=20020728022655.GA19087@krispykreme \
    --to=anton@samba.org \
    --cc=kevin.hendricks@sympatico.ca \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=yellowdog-devel@lists.terrasoftsolutions.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;
as well as URLs for NNTP newsgroup(s).