From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Wagner Subject: Re: [PATCH v3 0/2] Use blocked_lock_lock only to protect blocked_hash Date: Thu, 26 Mar 2015 14:55:38 +0100 Message-ID: <55140FDA.4020504@bmw-carit.de> References: <1425628412-30259-1-git-send-email-daniel.wagner@bmw-carit.de> <20150307090041.16fbf4f8@tlielax.poochiereds.net> <54FEA948.2040209@bmw-carit.de> <20150314084038.6e3def76@tlielax.poochiereds.net> <5513DB47.7050504@bmw-carit.de> <20150326091729.29085942@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Cc: , , Alexander Viro , "J. Bruce Fields" , Andi Kleen To: Jeff Layton Return-path: Received: from mail.bmw-carit.de ([62.245.222.98]:45984 "EHLO mail.bmw-carit.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753036AbbCZNzn (ORCPT ); Thu, 26 Mar 2015 09:55:43 -0400 In-Reply-To: <20150326091729.29085942@tlielax.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: >> - 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