Re: [PATCH v5 6/7] locking/lockdep: Reuse freed chain_hlocks entries
From: Peter Zijlstra
Date: Wed Feb 05 2020 - 04:42:04 EST
On Tue, Feb 04, 2020 at 11:45:15AM -0500, Waiman Long wrote:
> On 2/4/20 7:36 AM, Peter Zijlstra wrote:
> > --- a/kernel/locking/lockdep_proc.c
> > +++ b/kernel/locking/lockdep_proc.c
> > @@ -278,9 +278,11 @@ static int lockdep_stats_show(struct seq
> > #ifdef CONFIG_PROVE_LOCKING
> > seq_printf(m, " dependency chains: %11lu [max: %lu]\n",
> > lock_chain_count(), MAX_LOCKDEP_CHAINS);
> > - seq_printf(m, " dependency chain hlocks: %11lu [max: %lu]\n",
> > - MAX_LOCKDEP_CHAIN_HLOCKS - nr_free_chain_hlocks,
> > + seq_printf(m, " dependency chain hlocks used: %11lu [max: %lu]\n",
> > + MAX_LOCKDEP_CHAIN_HLOCKS - (nr_free_chain_hlocks - nr_lost_chain_hlocks),
> > MAX_LOCKDEP_CHAIN_HLOCKS);
> > + seq_printf(m, " dependency chain hlocks free: %11lu\n", nr_free_chain_hlocks);
> > + seq_printf(m, " dependency chain hlocks lost: %11lu\n", nr_lost_chain_hlocks);
>
> I do have some comments on this. There are three buckets now - free,
> lost, used. They add up to MAX_LOCKDEP_CHAIN_HLOCKS. I don't think we
> need to list all three. We can compute the third one by subtracting max
> from the other two.
>
> Something like:
>
> diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
> index 14932ea50317..6fe6a21c58d3 100644
> --- a/kernel/locking/lockdep_proc.c
> +++ b/kernel/locking/lockdep_proc.c
> @@ -278,9 +278,12 @@ static int lockdep_stats_show(struct seq_file *m,
> void *v)
> #ifdef CONFIG_PROVE_LOCKING
> seq_printf(m, " dependency chains: %11lu [max: %lu]\n",
> lock_chain_count(), MAX_LOCKDEP_CHAINS);
> - seq_printf(m, " dependency chain hlocks: %11lu [max: %lu]\n",
> - MAX_LOCKDEP_CHAIN_HLOCKS - nr_free_chain_hlocks,
> + seq_printf(m, " dependency chain hlocks used: %11lu [max: %lu]\n",
> + MAX_LOCKDEP_CHAIN_HLOCKS -
> + (nr_free_chain_hlocks + nr_lost_chain_hlocks),
> MAX_LOCKDEP_CHAIN_HLOCKS);
> + seq_printf(m, " dependency chain hlocks lost: %11lu\n",
> + nr_lost_chain_hlocks);
> #endif
>
Sure, also I tihnk the compiler is unhappy about %lu vs 'unsigned int'
for some of them.