On Sat, Mar 21, 2020 at 10:49:04PM +0100, Thomas Gleixner wrote:
[...]
> >> +rwsems have grown interfaces which allow non owner release for special
> >> +purposes. This usage is problematic on PREEMPT_RT because PREEMPT_RT
> >> +substitutes all locking primitives except semaphores with RT-mutex
Joel Fernandes writes:
>> +rwlock_t
>> +
>> +
>> +rwlock_t is a multiple readers and single writer lock mechanism.
>> +
>> +On a non PREEMPT_RT enabled kernel rwlock_t is implemented as a spinning
>> +lock and the suffix rules of spinlock_t apply accordingly. The
>> +implementation is
Hi Thomas,
Just a few comments:
[...]
> +rtmutex
> +===
> +
> +RT-mutexes are mutexes with support for priority inheritance (PI).
> +
> +PI has limitations on non PREEMPT_RT enabled kernels due to preemption and
> +interrupt disabled sections.
> +
> +On a PREEMPT_RT enabled kernel most of
On Sat, Mar 21, 2020 at 11:26:06AM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> > On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
> >> I agree that what I tried to express is hard to parse, but it's at least
> >> halfways correct :)
> >
> > Apologies! That is
"Paul E. McKenney" writes:
> On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
>> I agree that what I tried to express is hard to parse, but it's at least
>> halfways correct :)
>
> Apologies! That is what I get for not looking it up in the source. :-/
>
> OK, so I am stupid
On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> > On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> >> "Paul E. McKenney" writes:
> >> >
> >> > - The soft interrupt related suffix (_bh()) still disables softirq
> >> >handlers.
"Paul E. McKenney" writes:
> On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
>> "Paul E. McKenney" writes:
>> >
>> > - The soft interrupt related suffix (_bh()) still disables softirq
>> >handlers. However, unlike non-PREEMPT_RT kernels (which disable
>> >preemption to
On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
> >
> > - The soft interrupt related suffix (_bh()) still disables softirq
> >handlers. However, unlike non-PREEMPT_RT kernels (which disable
> >preemption to get this effect), PREEMPT_RT
"Paul E. McKenney" writes:
>
> - The soft interrupt related suffix (_bh()) still disables softirq
>handlers. However, unlike non-PREEMPT_RT kernels (which disable
>preemption to get this effect), PREEMPT_RT kernels use a per-CPU
>lock to exclude softirq handlers.
I've made that:
On Thu, Mar 19, 2020 at 07:02:17PM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
>
> > On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
> >
> > Mostly native-English-speaker services below, so please feel free to
> > ignore. The one place I made a
Jonathan Corbet writes:
> On Wed, 18 Mar 2020 21:43:10 +0100
> Thomas Gleixner wrote:
>> Add initial documentation.
>
> ...time to add a a couple of nits...:)
...time
Is that valid RST?
>> +++ b/Documentation/locking/locktypes.rst
>> @@ -0,0 +1,298 @@
>> +.. _kernel_hacking_locktypes:
>> +
>
Paul,
"Paul E. McKenney" writes:
> On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
>
> Mostly native-English-speaker services below, so please feel free to
> ignore. The one place I made a substantive change, I marked it "@@@".
> I only did about half of this document, but
On Wed, 18 Mar 2020 21:43:10 +0100
Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The kernel provides a variety of locking primitives. The nesting of these
> lock types and the implications of them on RT enabled kernels is nowhere
> documented.
>
> Add initial documentation.
...time to
On Wed, 18 Mar 2020, Thomas Gleixner wrote:
+Owner semantics
+===
+
+Most lock types in the Linux kernel have strict owner semantics, i.e. the
+context (task) which acquires a lock has to release it.
+
+There are two exceptions:
+
+ - semaphores
+ - rwsems
+
+semaphores have no
On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The kernel provides a variety of locking primitives. The nesting of these
> lock types and the implications of them on RT enabled kernels is nowhere
> documented.
>
> Add initial documentation.
>
>
15 matches
Mail list logo
