Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1552123
| From | Waiman Long <longman@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks |
| Date | 2017-01-05 18:10 +0100 |
| Message-ID | <sWjI6-5Ut-39@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <sVTui-55P-21@gated-at.bofh.it> <sVVFL-6tl-3@gated-at.bofh.it> <sWcQi-1a1-15@gated-at.bofh.it> <sWiM1-5ja-25@gated-at.bofh.it> <sWiM1-5ja-37@gated-at.bofh.it> |
| Organization | Red Hat |
On 01/05/2017 11:08 AM, Peter Zijlstra wrote: > On Thu, Jan 05, 2017 at 10:55:55AM -0500, Waiman Long wrote: >> What I am saying that we don't need to change spinlock to rtmutex in a >> -RT kernel. Instead, we can use rtqspinlock for this purpose. All the >> sleeping locks will still be converted to rtmutex. > No-no-no.. > >> Conversion of rtmutex does allow forced CPU preemption when there is a >> need for that. What rtqspinlock can provide is voluntary preemption >> where the lock waiters explicitly yield the CPU while waiting for the >> lock. I use the need_resched() to detect if CPU yielding is necessary. >> However, if the CPU was in a preempt disabled region before the >> spin_lock() call, we can't yield the CPU. The only way is to raise its >> priority and try to get the lock ASAP. > And here you've lost your finger because the saw-blade didn't stop in > time. Well, I lost my virtual fingers all the time;-) This is one way that I learn and become stronger. > RT very fundamentally relies on the spinlock->rtmutex conversion to > allow preempting things when a higher priority task comes along. A > spinlock, of any kind, requires having preemption disabled while holding > the lock. If the critical section is of unbounded latency, you have > unbounded preemption latency and RT is no more. > > Its not about PI on contention, although that helps inversion scenarios. > Its about allowing preemption, which fundamentally requires a sleeping > lock to be used. > > Many of the spinlock sections of mainline are not well behaved in an RT > sense and therefore must not disable preemption. Similar for the IRQ > disable regions and hence we have the whole threaded interrupt stuff. I do make the assumption that spinlock critical sections are behaving well enough. Apparently, that is not a valid assumption. I sent these RFC patches out to see if it was an idea worth pursuing. If not, I can drop these patches. Anyway, thanks for the feedback. Cheers, Longman
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-03 19:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Peter Zijlstra <peterz@infradead.org> - 2017-01-04 14:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-04 16:30 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Steven Rostedt <rostedt@goodmis.org> - 2017-01-04 17:00 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-04 21:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Steven Rostedt <rostedt@goodmis.org> - 2017-01-05 19:50 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Daniel Bristot de Oliveira <bristot@redhat.com> - 2017-01-05 10:30 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Peter Zijlstra <peterz@infradead.org> - 2017-01-05 10:50 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Peter Zijlstra <peterz@infradead.org> - 2017-01-05 17:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-05 18:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Steven Rostedt <rostedt@goodmis.org> - 2017-01-05 20:00 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-05 20:30 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Daniel Bristot de Oliveira <bristot@redhat.com> - 2017-01-05 19:10 +0100
Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks Waiman Long <longman@redhat.com> - 2017-01-05 17:10 +0100
csiph-web