On Thu, Sep 26, 2024 at 09:54:33AM -0700, Linus Torvalds wrote:
> On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser
> <jonas.oberhau...@huaweicloud.com> wrote:
> >
> > Boqun seems to be unhappy with a barrier though, because it would
> > theoretically also forbid unrelated optimizations.
>
> Well, doing a "barrier()" is kind of a big hammer thing, but honestly,
> I don't think we've ever seen any real situation where it makes a
> noticeable difference. Yes, it can pessimize compiler output more than
> strictly necessary, but the kind of code generation issues it causes
> tends to be the non-problematic kind (and particularly the kind that
> even a trivial OoO core will deal with well).
>
> We do have some more directed compiler barriers available, and this
> code might be able to use OPTIMIZER_HIDE_VAR() for example. It's kind
> of a "single variable value barrier".
>
Hmm.. this seems can do the trick?
#define ADDRESS_EQ(var, expr)
\
({
\
bool _____cmp_res = (unsigned long)(var) == (unsigned
long)(expr); \
\
OPTIMIZER_HIDE_VAR(var);
\
_____cmp_res;
\
})
i.e. compare the address and hide the equality information immediately,
so in hazptr code:
ptr = READ_ONCE(*p); // first read
if (ptr == NULL)
return NULL;
head = (struct callback_head *)(ptr + head_offset);
WRITE_ONCE(*hzp, head);
smp_mb();
ptr = READ_ONCE(*p); // read again
if (!ADDRESS_EQ(ptr, (void *)head - head_offset)) { // pointer changed
WRITE_ONCE(*hzp, NULL); // reset hazard pointer
return NULL;
} else {
// Optimizer lost the information on the value of 'ptr',
// so it cannot replace it with head - head_offset.
return ptr;
}
Regards,
Boqun
> Honestly, we don't use it much. It just tends to be _too_specific. But
> it is there if somebody wants to use it.
>
> > But I have not seen any evidence that there are any unrelated
> > optimizations going on in the first place that would be forbidden by this.
>
> Compared to something like "smp_mb()", which is not just a compiler
> barrier but also generates typically very expensive instructions that
> completely mess with an OoO core, a regular compiler barrier is a
> complete non-issue. When you have those two close to each other, you'd
> have to make up some very odd situation where the plain "barrier()" is
> even noticeable.
>
> Linus
>
