Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1550752
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks |
| Date | 2017-01-04 14:10 +0100 |
| Message-ID | <sVTui-55P-21@gated-at.bofh.it> (permalink) |
| References | <sVBH3-1F1-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Jan 03, 2017 at 01:00:23PM -0500, Waiman Long wrote: > This patchset introduces a new variant of queued spinlocks - the > realtime queued spinlocks. The purpose of this new variant is to > support real spinlock in a realtime environment where high priority > RT tasks should be allowed to complete its work ASAP. This means as > little waiting time for spinlocks as possible. > > Non-RT tasks will wait for spinlocks in the MCS waiting queue as > usual. RT tasks and interrupts will spin directly on the spinlocks > and use the priority value in the pending byte to arbitrate who get > the lock first. > > Patch 1 removes the unused spin_lock_bh_nested() API. > > Patch 2 introduces the basic realtime queued spinlocks where the > pending byte is used for storing the priority of the highest priority > RT task that is waiting on the spinlock. All the RT tasks will spin > directly on the spinlock instead of waiting in the queue. > OK, so a single numerical field isn't sufficient to describe priority anymore, since we added DEADLINE support things have gotten a lot more complex. Also, the whole approach worries me, it has the very real possibility of re-introducing a bunch of starvation cases avoided by the fair lock. Is there a real problem with -RT that inspired these patches?
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