Page MenuHomeFreeBSD

hyperv/vmbus: Avoid unnecessary mb()
ClosedPublic

Authored by sepherosa_gmail.com on Jul 27 2016, 8:38 AM.
Tags
None
Referenced Files
F170608018: D7333.id18799.diff
Sat, Sep 5, 3:12 PM
F170588392: D7333.diff
Sat, Sep 5, 1:09 PM
F170525169: D7333.diff
Sat, Sep 5, 5:59 AM
F170500503: D7333.id.diff
Sat, Sep 5, 3:07 AM
Unknown Object (File)
Thu, Sep 3, 2:27 AM
Unknown Object (File)
Wed, Sep 2, 9:56 PM
Unknown Object (File)
Wed, Sep 2, 2:22 AM
Unknown Object (File)
Tue, Sep 1, 7:10 AM
Subscribers
None

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sepherosa_gmail.com retitled this revision from to hyperv/vmbus: Avoid unnecessary mb().
sepherosa_gmail.com updated this object.
sepherosa_gmail.com edited the test plan for this revision. (Show Details)

How is this supposed to be reviewed ? Indeed, the patch changes compiler barrier + some fences into compiler barrier. Bit I have no idea why the change is safe, and what is the reason behind original code and this weaker variation.

Are you relying on the IA32 ordering guarantees ? If yes, then atomic_fence_acq() for read/any and atomic_fence_rel for any/write fencing is more clean.

In D7333#152520, @kib wrote:

How is this supposed to be reviewed ? Indeed, the patch changes compiler barrier + some fences into compiler barrier. Bit I have no idea why the change is safe, and what is the reason behind original code and this weaker variation.

Are you relying on the IA32 ordering guarantees ? If yes, then atomic_fence_acq() for read/any and atomic_fence_rel for any/write fencing is more clean.

Yeah, I am relying on IA32 ordering. Well, since the other side is in the hypervisor, I am not sure about whether fence_acq and fence_rel will be more readable or not (since acq and rel will not be paired).

This revision was automatically updated to reflect the committed changes.