From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751447AbcGRBsT (ORCPT ); Sun, 17 Jul 2016 21:48:19 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:47493 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751330AbcGRBsR (ORCPT ); Sun, 17 Jul 2016 21:48:17 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Mon, 18 Jul 2016 10:46:17 +0900 From: Byungchul Park To: Peter Zijlstra Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com, gregkh@linuxfoundation.org, minchan@kernel.org, Thomas Gleixner Subject: Re: [PATCH 1/5] lockdep: Implement bitlock map allocator Message-ID: <20160718014617.GK2279@X58A-UD3R> References: <1466398515-1005-1-git-send-email-byungchul.park@lge.com> <1466398515-1005-2-git-send-email-byungchul.park@lge.com> <20160630125919.GD30154@twins.programming.kicks-ass.net> <20160701002444.GV2279@X58A-UD3R> <20160701075312.GL30921@twins.programming.kicks-ass.net> <20160704072925.GY2279@X58A-UD3R> <20160713201754.GE30921@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713201754.GE30921@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 13, 2016 at 10:17:54PM +0200, Peter Zijlstra wrote: > On Mon, Jul 04, 2016 at 04:29:25PM +0900, Byungchul Park wrote: > > On Fri, Jul 01, 2016 at 09:53:12AM +0200, Peter Zijlstra wrote: > > > On Fri, Jul 01, 2016 at 09:24:44AM +0900, Byungchul Park wrote: > > > > On Thu, Jun 30, 2016 at 02:59:19PM +0200, Peter Zijlstra wrote: > > > > > On Mon, Jun 20, 2016 at 01:55:11PM +0900, Byungchul Park wrote: > > > > > > > > > > > +struct bitlock_map { > > > > > > + struct hlist_node hash_entry; > > > > > > + unsigned long bitaddr; /* ID */ > > > > > > + struct lockdep_map map; > > > > > > + int ref; /* reference count */ > > > > > > +}; > > > > > > > > > > So this is effectively bigger than just adding a struct lockdep_map into > > > > > whatever structure holds the bit spinlock to begin with. > > > > > > > > > > What is the gain? > > > > > > > > 1. I don't want to make being aware of lockdep essential to user of > > > > bit-base lock, like spin lock, mutex, semaphore ans so on. In other > > > > words, I want to make it work transparently. > > > > > > I want to discourage the use of bitlocks, they stink. > > > > I agree it has some problems. But someone who are sensive to memory > > consumption still need to use bit-based lock. Right? > > > > I can stop this proposal because it's meaningless if bit-based lock can be > > removed entirely since any requirement for bit-based lock does not exist > > at all. But IMHO, it's worthy if the requirement be. > > > > > bitlocks must by their constraint be a test-and-set lock, with all the > > > known problems those have. It also means they're a royal pain for -rt. > > > > I also think it's better to use rather spinlock in most cases unless memory > > consumption is critical problem. But in the case memory consumption is > > critical... what can we do? > > So RT is already patching a whole bunch of bit-spinlocks into proper > spinlocks, I would much rather we do that and get lockdep coverage that > way. > > That is, have the bit-spinlock for 'normal' kernels and use the proper > spinlock for LOCKDEP || PREEMPT_RT kernels. Yes. It makes sense to me. Thank you for answering it.