linux-kernel - Re: [PATCH v3 0/2] Use blocked_lock_lock only to protect blocked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2015 14:55:38 +0100
From:	Daniel Wagner <daniel.wagner@...-carit.de>
To:	Jeff Layton <jlayton@...chiereds.net>
CC:	<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v3 0/2] Use blocked_lock_lock only to protect blocked_hash

>>  - 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/