lkml.org 
[lkml]   [2004]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86 bitops.h commentary on instruction reordering
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.086 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site