Page MenuHomeFreeBSD

hyperv/vmbus: Avoid unnecessary mb()
ClosedPublic

Authored by sepherosa_gmail.com on Jul 27 2016, 8:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jul 28, 8:27 PM
Unknown Object (File)
Mon, Jul 28, 7:39 AM
Unknown Object (File)
Tue, Jul 22, 1:27 PM
Unknown Object (File)
Mon, Jul 14, 9:53 AM
Unknown Object (File)
Sun, Jul 6, 8:19 AM
Unknown Object (File)
Sat, Jul 5, 5:33 AM
Unknown Object (File)
Fri, Jul 4, 5:46 PM
Unknown Object (File)
Fri, Jul 4, 10:13 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.