Page MenuHomeFreeBSD

HyperV/vmm: improve locking of hv_ring_buffer
AbandonedPublic

Authored by howard0su_gmail.com on Feb 2 2016, 5:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 12, 3:09 AM
Unknown Object (File)
Wed, Apr 10, 3:36 AM
Unknown Object (File)
Feb 22 2024, 2:32 PM
Unknown Object (File)
Dec 20 2023, 2:00 AM
Unknown Object (File)
Dec 5 2023, 6:50 PM
Unknown Object (File)
Nov 13 2023, 12:26 PM
Unknown Object (File)
Nov 11 2023, 5:54 AM
Unknown Object (File)
Nov 11 2023, 4:44 AM

Details

Summary
  1. convert spin lock to def lock
  2. reading always happen in single thread, remove lock protection

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 2358
Build 2374: arc lint + arc unit

Event Timeline

howard0su_gmail.com retitled this revision from to HyperV/vmm: improve locking of hv_ring_buffer.
howard0su_gmail.com updated this object.
howard0su_gmail.com edited the test plan for this revision. (Show Details)
sepherosa_gmail.com edited edge metadata.

Seems reasonable to me

This revision is now accepted and ready to land.Feb 5 2016, 12:17 PM
sys/dev/hyperv/vmbus/hv_ring_buffer.c
357

So this is nit picking, but do yo need memory barriers here if you intend to peek? the lock ends up being effectively a memory barrier..

No. Since read/peek are happened in single thread, no mb is needed. Peek is just a normal read except it copies less data and doesn't advance the read position.

I just double checked the code. It is not MPSAFE to process the recv ring w/o lock, e.g. storvsc_poll(), which could be called in another thread. I think the spinlock -> default mtx change should be fine.

I just double checked the code. It is not MPSAFE to process the recv ring w/o lock, e.g. storvsc_poll(), which could be called in another thread. I think the spinlock -> default mtx change should be fine.

I think we could pass a flag down to the recv ring read/peek, so that we could do lockless read for other drivers.