Page MenuHomeFreeBSD

Add mutex implementation that uses high irq-level instead of locking interrupts.
Needs ReviewPublic

Authored by p.bruenn_beckhoff.com on Mon, May 18, 7:11 AM.

Details

Reviewers
ian
mjg
kib
jhb
Summary

Locking all interrupts interferes with realtime applications and accessing the
AT-RTC is an operation, which is used by such realtime applications.
We added a mutex implementation that uses high irq-level locking and change the
AT-RTC implementation to use it for low-lewel access of CMOS. The tunable
"machdep.atrtc_use_high_irql" can be set to "1" to activate the new behavior.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 31142
Build 28820: arc lint + arc unit

Event Timeline

p.bruenn_beckhoff.com requested review of this revision.Mon, May 18, 7:11 AM
p.bruenn_beckhoff.com created this revision.

I found your names in the history of affected files and want to ask you, if this patch would be of interest for upstream FreeBSD. We use it for https://www.beckhoff.com/twincat-bsd/.

kib added a comment.Mon, May 18, 1:28 PM

There is a lot of issues with the patch as-is. e.g.

  • it is x86 only. I do not mean that it should use LAPIC and %cr8 on other arches where the hardware is different, but that the code is not structured to have machine-independent and machine-dependent parts
  • there is no fences semantic (locks should provide acq/rel on lock/unlock)
  • there is no integration with FreeBSD locking infrastructure, most important would be witness.

I do not object, only mean that there is a lot to work on to make this patch committable.

Also, I beleive that John Baldwin had a generic implementation of spin locks using task priority register, with the goal of reducing the TLB shootdown IPI overhead. I will add him.

kib added a reviewer: jhb.Mon, May 18, 1:29 PM

Thanks for the fast feedback. Yes, we are aware that this patch is not merge able in the current state, but before we put more effort into platforms, which we don't need ourself, we wanted to make sure there is honest interest in the community.
If John has better approach, we would happily volunteer to test his patches ;-).