From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753075AbbCZNzv (ORCPT ); Thu, 26 Mar 2015 09:55:51 -0400 Received: from mail.bmw-carit.de ([62.245.222.98]:45985 "EHLO mail.bmw-carit.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753047AbbCZNzq (ORCPT ); Thu, 26 Mar 2015 09:55:46 -0400 Message-ID: <55140FDA.4020504@bmw-carit.de> Date: Thu, 26 Mar 2015 14:55:38 +0100 From: Daniel Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeff Layton CC: , , Alexander Viro , "J. Bruce Fields" , Andi Kleen Subject: Re: [PATCH v3 0/2] Use blocked_lock_lock only to protect blocked_hash 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> In-Reply-To: <20150326091729.29085942@tlielax.poochiereds.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> - 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