From: linux@horizon.com
To: dev@sw.ru
Cc: linux-kernel@vger.kernel.org
Subject: Re: SMP syncronization on AMD processors (broken?)
Date: 11 Oct 2005 19:50:17 -0400 [thread overview]
Message-ID: <20051011235017.21719.qmail@science.horizon.com> (raw)
> The whole story started when we wrote the following code:
>
> void XXX(void)
> {
> /* ints disabled */
> restart:
> spin_lock(&lock);
> do_something();
> if (!flag)
> need_restart = 1;
> spin_unlock(&lock);
> if (need_restart)
> goto restart; <<<< LOOPS 4EVER ON AMD!!!
> }
>
> void YYY(void)
> {
> spin_lock(&lock); <<<< SPINS 4EVER ON AMD!!!
> flag = 1;
> spin_unlock(&lock);
> }
>
> function XXX() starts on CPU0 and begins to loop since flag is not set,
> then CPU1 calls function YYY() and it turns out that it can't take the
> lock any arbitrary time.
The right thing to do here is to wait for the flag to be set *outside*
the lock, and then re-validate inside the lock:
void XXX(void)
{
/* ints disabled */
restart:
spin_lock(&lock);
do_something();
if (!flag)
need_restart = 1;
spin_unlock(&lock);
if (need_restart) {
while (!flag)
cpu_relax();
goto restart;
}
}
This way, XXX() keeps the lock dropped for as long as it takes for
YYY() to notice and grab it.
However, I realize that this is of course a simplified case of some real
code, where even *finding* the flag requires the spin lock.
The generic solution is to have a global "progress" counter, which
records "I made progress toward setting flag", that XXX() can
busy-loop on:
int progress;
void XXX(void)
{
int old_progress;
/* ints disabled */
restart:
spin_lock(&lock);
do_something();
if (!flag) {
old_progress = progress;
need_restart = 1;
}
spin_unlock(&lock);
if (need_restart) {
while (progress == old_progress)
cpu_relax();
goto restart;
}
}
void YYY(void)
{
spin_lock(&lock);
flag = 1;
progress++;
spin_unlock(&lock);
}
It may be that in your data structure, there is one or a series of
fields that already exist that you can use for the purpose. The goal
is to merely detect *change*, so you can reacquire the lock and test
definitively. It's okay to read freed memory while doing this, as long as
you can be sure that:
- The memory read won't oops the kernel, and
- You don't end up depending on the value of the freed memory to
get you out of the stall.
next reply other threads:[~2005-10-11 23:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-11 23:50 linux [this message]
2005-10-12 2:12 ` Christopher Friesen
2005-10-12 2:39 ` linux
2005-10-12 3:27 ` Kyle Moffett
2005-10-13 12:25 ` Kirill Korotaev
-- strict thread matches above, loose matches on Subject: below --
2005-10-08 9:31 Chuck Ebbert
2005-10-06 13:05 Kirill Korotaev
2005-10-06 13:14 ` linux-os (Dick Johnson)
2005-10-06 13:19 ` Arjan van de Ven
2005-10-06 13:32 ` Andrey Savochkin
2005-10-06 14:22 ` Arjan van de Ven
2005-10-06 13:32 ` Andi Kleen
2005-10-06 13:46 ` Andrey Savochkin
2005-10-06 14:52 ` Linus Torvalds
2005-10-06 15:21 ` Andrey Savochkin
2005-10-06 15:46 ` Linus Torvalds
2005-10-11 0:59 ` Andrew Morton
2005-10-11 1:20 ` Andi Kleen
2005-10-11 3:20 ` Joe Seigh
2005-10-06 13:50 ` Eric Dumazet
2005-10-06 14:45 ` Linus Torvalds
2005-10-06 15:34 ` Hugh Dickins
2005-10-06 15:53 ` Eric Dumazet
2005-10-06 16:01 ` Linus Torvalds
2005-10-07 20:38 ` Joe Seigh
2005-10-07 20:57 ` Stephen Hemminger
2005-10-13 18:24 ` Joe Seigh
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=20051011235017.21719.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=dev@sw.ru \
--cc=linux-kernel@vger.kernel.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®