From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86 bitops.h commentary on instruction reordering
Date: Tue, 10 Aug 2004 00:12:16 +0400 [thread overview]
Message-ID: <4117DAA0.1020601@vlnb.net> (raw)
In-Reply-To: <20040809183437.GD6361@logos.cnet>
Marcelo Tosatti wrote:
> Vladislav,
>
> There is no cache coherency issues on x86, it handles the cache coherency
> on hardware.
Well, Marcelo, sorry if I'm getting too annoying, but we had a race with
cache coherency during SCST (SCSI target mid-level) development. We
discovered that on P4 Xeon after atomic_set() there is very small
window, when atomic_read() on another CPUs returns the old value. We had
to rewrite the code without using atomic_set(). Isn't it cache coherency
issue?
And, BTW, returning to the original topic, would it be better to make
set_bit() and friends guarantee not to be reordered on all
architectures, instead of just add the comment. Otherwise, what is the
difference with versions with `__` prefix (__set_bit(), for example)?
Just adding the comments will lead to creating different functions with
gurantees by everyone who need it in all over the kernel. Is it the
right thing? In some places in SCST we heavy rely on non-ordering
guarantees.
Thanks,
Vlad
next prev parent reply other threads:[~2004-08-09 20:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 20:06 [PATCH] x86 bitops.h commentary on instruction reordering Marcelo Tosatti
2004-08-06 14:17 ` Vladislav Bolkhovitin
2004-08-06 14:33 ` Marcelo Tosatti
2004-08-06 15:36 ` Vladislav Bolkhovitin
2004-08-06 15:53 ` Marcelo Tosatti
2004-08-06 16:52 ` Vladislav Bolkhovitin
2004-08-06 17:09 ` Marcelo Tosatti
2004-08-06 22:33 ` H. Peter Anvin
2004-08-07 1:01 ` Zwane Mwaikambo
2004-08-07 22:16 ` Alan Cox
2004-08-09 15:14 ` Vladislav Bolkhovitin
2004-08-09 15:50 ` Marcelo Tosatti
2004-08-09 17:35 ` Vladislav Bolkhovitin
[not found] ` <20040809183437.GD6361@logos.cnet>
2004-08-09 20:12 ` Vladislav Bolkhovitin [this message]
2004-08-09 21:21 ` Alan Cox
2004-08-10 12:28 ` Vladislav Bolkhovitin
2004-08-09 11:58 ` Maciej W. Rozycki
[not found] <2pY7Y-W1-7@gated-at.bofh.it>
[not found] ` <2qdJL-3sh-27@gated-at.bofh.it>
[not found] ` <2qePx-4eM-21@gated-at.bofh.it>
[not found] ` <2qf8S-4pI-31@gated-at.bofh.it>
[not found] ` <2qg4V-54c-17@gated-at.bofh.it>
[not found] ` <2qgoh-5og-29@gated-at.bofh.it>
[not found] ` <2qhkn-649-41@gated-at.bofh.it>
[not found] ` <2rkgh-zP-45@gated-at.bofh.it>
[not found] ` <2rlFk-1wC-27@gated-at.bofh.it>
[not found] ` <2rmhX-20I-17@gated-at.bofh.it>
[not found] ` <2roWw-40d-19@gated-at.bofh.it>
[not found] ` <2roWw-40d-17@gated-at.bofh.it>
2004-08-09 21:23 ` Andi Kleen
2004-08-10 12:26 ` Vladislav Bolkhovitin
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=4117DAA0.1020601@vlnb.net \
--to=vst@vlnb.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.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