From: Peter Zijlstra <peterz@infradead.org>
To: Byungchul Park <byungchul.park@lge.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
sergey.senozhatsky@gmail.com, gregkh@linuxfoundation.org,
minchan@kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/5] lockdep: Implement bitlock map allocator
Date: Wed, 13 Jul 2016 22:17:54 +0200 [thread overview]
Message-ID: <20160713201754.GE30921@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160704072925.GY2279@X58A-UD3R>
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.
next prev parent reply other threads:[~2016-07-13 20:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 4:55 [PATCH 0/5] Implement bitlock map allocator Byungchul Park
2016-06-20 4:55 ` [PATCH 1/5] lockdep: " Byungchul Park
2016-06-30 12:59 ` Peter Zijlstra
2016-07-01 0:24 ` Byungchul Park
2016-07-01 7:53 ` Peter Zijlstra
2016-07-04 7:29 ` Byungchul Park
2016-07-07 10:22 ` Byungchul Park
2016-07-13 20:17 ` Peter Zijlstra [this message]
2016-07-18 1:46 ` Byungchul Park
2016-06-20 4:55 ` [PATCH 2/5] lockdep: Apply bitlock to bit_spin_lock Byungchul Park
2016-06-20 4:55 ` [PATCH 3/5] lockdep: Apply bit_spin_lock lockdep to zram Byungchul Park
2016-06-20 15:36 ` Sergey Senozhatsky
2016-06-21 1:05 ` Byungchul Park
2016-06-20 4:55 ` [PATCH 4/5] fs/buffer.c: Remove trailing white space Byungchul Park
2016-06-20 4:55 ` [PATCH 5/5] lockdep: Apply bit_spin_lock lockdep to BH_Uptodate_Lock Byungchul Park
2016-06-29 12:45 ` [PATCH 0/5] Implement bitlock map allocator Byungchul Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160713201754.GE30921@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=byungchul.park@lge.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=mingo@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.