Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1442810 > unrolled thread

Re: [PATCH 1/5] lockdep: Implement bitlock map allocator

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/5] lockdep: Implement bitlock map allocator Peter Zijlstra <peterz@infradead.org> - 2016-07-13 22:20 +0200
    Re: [PATCH 1/5] lockdep: Implement bitlock map allocator Byungchul Park <byungchul.park@lge.com> - 2016-07-18 03:50 +0200

#1442810 — Re: [PATCH 1/5] lockdep: Implement bitlock map allocator

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.

[toc] | [next] | [standalone]

#1445152

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web