On 08/27/2012 09:24 AM, Anthony Liguori wrote: > > > > I'm sure we should leave existing code alone wherever possible, focusing > > on providing alternative versions for those paths that matter. Example: > > Most timers are fine under BQL. But some sensitive devices (RTC or HPET > > as clock source) will want their own timers. So the approach is to > > instantiate a separate, also prioritizeable instance of the timer > > subsystem for them and be done. > > I disagree. I think we conver the timer subsystem to be lockless and > then let some devices acquire the BQL during dispatch.
I agree with your disagreement but disagree with the rest. The timer subsystem should have its own internal locking that callers will not be aware of. Requiring devices to acquire the bql will lead to deadlocks. Note that fine-grained locking timers will also require reference counting: you want to call the timer expiration callback after releasing the timer subsystem lock, so you need to make sure the callback does not go away. Linux manages without it (hrtimer_interrupt), so maybe we can too. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
