Re: [PATCH v3 0/2] Use blocked_lock_lock only to protect blocked_hash

[Daniel Wagner <daniel.wagner@bmw-carit.de>]

>>  - I also played with lockdep detection. With lglock-v0 applied
>>    some tests like flock02 and posix02 get considerable worse
>>    results. The difference between flock01 and flock02 is that
>>    the children of flock01 fight over one file lock versus
>>    the children of flock02 lock and unlock their own lock.
>>    My best guess is that the lockdep tracing is adding
>>    far more to the per child lock configuration. I didn't find
>>    any other explanation than this. Although I have to admit
>>    I can't find a good argument why this makes a difference
>>    between arch_spinlock_t and spinlock_t. 
>>

[...]

> lockdep has overhead, and when you move from arch_spinlock_t to
> "normal" spinlock_t's you end up with per-spinlock lockdep structures.
> I wouldn't worry much about performance with lockdep enabled.

That was the missing piece. Okay, that explains the performance degradation.

>>> You had mentioned at one point that lglocks didn't play well with the
>>> -rt kernels. What's the actual problem there?
>>
>> -rt kernels like to preempt everything possible. One mean to achieve
>> this is by exchanging normal spinlock_t with rt_mutex. arch_spinlock_t
>> does not get this treatment automatically via the lock framework. 
>> For this following patch is carried around:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v3.14-rt-rebase&id=da1cbed0dcf6ab22a4b50b0c5606271067749aef
>>
>>  struct lglock {
>> +#ifndef CONFIG_PREEMPT_RT_FULL
>>         arch_spinlock_t __percpu *lock;
>> +#else
>> +       struct rt_mutex __percpu *lock;
>> +#endif
>>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
>>         struct lock_class_key lock_key;
>>         struct lockdep_map    lock_dep_map;
>>  #endif
>>  };
>>
>> [...]
>>
> 
> Ok. Is that approach problematic in some way?

I expect that mainline wont accept such a patch :). T

> I'm trying to understand the exact problem that you're
> trying to solve for -rt with this effort.

My aim is to rid of the -rt patches and mainline the features. This here
is just my small contribution to the whole -rt effort.

cheers,
daniel