All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: mingo@redhat.com, tj@kernel.org, johannes.berg@intel.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use
Date: Thu, 29 Nov 2018 13:01:43 +0100	[thread overview]
Message-ID: <20181129120143.GG2149@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181129104902.GH2131@hirez.programming.kicks-ass.net>

On Thu, Nov 29, 2018 at 11:49:02AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 28, 2018 at 03:43:20PM -0800, Bart Van Assche wrote:
> > Instead of abandoning elements of list_entries[] that are no longer in
> > use, make alloc_list_entry() reuse array elements that have been freed.
> 
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index 43327a1dd488..01e55fca7c2c 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -183,6 +183,11 @@ static inline void lockdep_copy_map(struct lockdep_map *to,
> >  struct lock_list {
> >  	/* Entry in locks_after or locks_before. */
> >  	struct list_head		lock_order_entry;
> > +	/*
> > +	 * Entry in all_list_entries when in use and entry in
> > +	 * free_list_entries when not in use.
> > +	 */
> > +	struct list_head		alloc_entry;
> >  	struct lock_class		*class;
> >  	struct lock_class		*links_to;
> >  	struct stack_trace		trace;
> 
> > +static LIST_HEAD(all_list_entries);
> > +static LIST_HEAD(free_list_entries);
> >  
> 
> > @@ -862,7 +867,10 @@ register_lock_class(struct lockdep_map *lock, unsigned int subclass, int force)
> >   */
> >  static struct lock_list *alloc_list_entry(void)
> >  {
> > -	if (nr_list_entries >= MAX_LOCKDEP_ENTRIES) {
> > +	struct lock_list *e = list_first_entry_or_null(&free_list_entries,
> > +						       typeof(*e), alloc_entry);
> > +
> > +	if (!e) {
> >  		if (!debug_locks_off_graph_unlock())
> >  			return NULL;
> >  
> > @@ -870,7 +878,8 @@ static struct lock_list *alloc_list_entry(void)
> >  		dump_stack();
> >  		return NULL;
> >  	}
> > -	return list_entries + nr_list_entries++;
> > +	list_move_tail(&e->alloc_entry, &all_list_entries);
> > +	return e;
> >  }
> 
> > @@ -4235,19 +4244,19 @@ static void zap_class(struct list_head *zapped_classes,
> >  		      struct lock_class *class)
> >  {
> >  	struct lock_class *links_to;
> > +	struct lock_list *entry, *tmp;
> >  
> >  	/*
> >  	 * Remove all dependencies this lock is
> >  	 * involved in:
> >  	 */
> > +	list_for_each_entry_safe(entry, tmp, &all_list_entries, alloc_entry) {
> >  		if (entry->class != class && entry->links_to != class)
> >  			continue;
> >  		links_to = entry->links_to;
> >  		WARN_ON_ONCE(entry->class == links_to);
> >  		list_del_rcu(&entry->lock_order_entry);
> > +		list_move(&entry->alloc_entry, &free_list_entries);
> >  		entry->class = NULL;
> >  		entry->links_to = NULL;
> >  		check_free_class(zapped_classes, class);
> 
> Hurm.. I'm confused here.
> 
> The reason you cannot re-use lock_order_entry for the free list is
> because list_del_rcu(), right? But if so, then what ensures the
> list_entry is not re-used before it's grace-period?

Also; if you have to grow lock_list by 16 bytes just to be able to free
it, a bitmap allocator is much cheaper, space wise.

Some people seem to really care about the static image size, and
lockdep's .data section does matter to them.

  reply	other threads:[~2018-11-29 12:01 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 23:42 [PATCH 00/27] locking/lockdep: Add support for dynamic keys Bart Van Assche
2018-11-28 23:42 ` [PATCH 01/27] lockdep tests: Display compiler warning and error messages Bart Van Assche
2018-11-28 23:43 ` [PATCH 02/27] lockdep tests: Fix shellcheck warnings Bart Van Assche
2018-11-28 23:43 ` [PATCH 03/27] lockdep tests: Improve testing accuracy Bart Van Assche
2018-11-28 23:43 ` [PATCH 04/27] lockdep tests: Run lockdep tests a second time under Valgrind Bart Van Assche
2018-11-28 23:43 ` [PATCH 05/27] liblockdep: Rename "trywlock" into "trywrlock" Bart Van Assche
2018-11-28 23:43 ` [PATCH 06/27] liblockdep: Add dummy print_irqtrace_events() implementation Bart Van Assche
2018-11-28 23:43 ` [PATCH 07/27] lockdep tests: Test the lockdep_reset_lock() implementation Bart Van Assche
2018-11-28 23:43 ` [PATCH 08/27] locking/lockdep: Declare local symbols static Bart Van Assche
2018-11-28 23:43 ` [PATCH 09/27] locking/lockdep: Inline __lockdep_init_map() Bart Van Assche
2018-11-28 23:43 ` [PATCH 10/27] locking/lockdep: Introduce lock_class_cache_is_registered() Bart Van Assche
2018-11-28 23:43 ` [PATCH 11/27] timekeeping: Assign a name to tk_core.seq.dep_map Bart Van Assche
2018-12-05 10:03   ` [tip:timers/core] timekeeping: Use proper seqcount initializer tip-bot for Bart Van Assche
2018-11-28 23:43 ` [PATCH 12/27] net/core: Assign a name to devnet_rename_seq.dep_map Bart Van Assche
2018-11-29  0:45   ` David Miller
2018-11-28 23:43 ` [PATCH 13/27] locking/lockdep: Complain if a lock object has no name Bart Van Assche
2018-11-28 23:43 ` [PATCH 14/27] locking/lockdep: Remove a superfluous INIT_LIST_HEAD() statement Bart Van Assche
2018-11-28 23:43 ` [PATCH 15/27] locking/lockdep: Make concurrent lockdep_reset_lock() calls safe Bart Van Assche
2018-11-28 23:43 ` [PATCH 16/27] locking/lockdep: Stop using RCU primitives to access all_lock_classes Bart Van Assche
2018-11-28 23:43 ` [PATCH 17/27] locking/lockdep: Make zap_class() remove all matching lock order entries Bart Van Assche
2018-11-28 23:43 ` [PATCH 18/27] locking/lockdep: Reorder struct lock_class members Bart Van Assche
2018-11-28 23:43 ` [PATCH 19/27] locking/lockdep: Retain the class key and name while freeing a lock class Bart Van Assche
2018-11-28 23:43 ` [PATCH 20/27] locking/lockdep: Free lock classes that are no longer in use Bart Van Assche
2018-11-29 10:37   ` Peter Zijlstra
2018-11-28 23:43 ` [PATCH 21/27] locking/lockdep: Rename lock_list.entry into lock_list.lock_order_entry Bart Van Assche
2018-11-28 23:43 ` [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use Bart Van Assche
2018-11-29 10:49   ` Peter Zijlstra
2018-11-29 12:01     ` Peter Zijlstra [this message]
2018-11-29 16:48       ` Bart Van Assche
2018-12-01 20:24         ` Peter Zijlstra
2018-12-03 16:40           ` Bart Van Assche
2018-12-03 17:32             ` Peter Zijlstra
2018-12-03 18:16               ` Bart Van Assche
2018-12-04  8:14                 ` Peter Zijlstra
2018-12-04 16:08                   ` Bart Van Assche
2018-11-28 23:43 ` [PATCH 23/27] locking/lockdep: Check data structure consistency Bart Van Assche
2018-11-29 12:30   ` Peter Zijlstra
2018-11-29 16:50     ` Bart Van Assche
2018-11-29 16:59       ` Peter Zijlstra
2018-11-28 23:43 ` [PATCH 24/27] locking/lockdep: Introduce __lockdep_free_key_range() Bart Van Assche
2018-11-29 10:00   ` Peter Zijlstra
2018-11-28 23:43 ` [PATCH 25/27] locking/lockdep: Add support for dynamic keys Bart Van Assche
2018-11-29 10:10   ` Peter Zijlstra
2018-12-03 17:07     ` Bart Van Assche
2018-12-03 17:31       ` Peter Zijlstra
2018-11-29 12:04   ` Peter Zijlstra
2018-11-29 16:59     ` Bart Van Assche
2018-11-28 23:43 ` [PATCH 26/27] kernel/workqueue: Use dynamic lockdep keys for workqueues Bart Van Assche
2018-11-28 23:43 ` [PATCH 27/27] lockdep tests: Test dynamic key registration Bart Van Assche
2018-11-29 12:31 ` [PATCH 00/27] locking/lockdep: Add support for dynamic keys Peter Zijlstra

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=20181129120143.GG2149@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bvanassche@acm.org \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tj@kernel.org \
    /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.