Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <607c446bc8d3a0cc6e96aa9792e075913ad6b2c6.camel@redhat.com>
Subject: Re: [RFC v7 11/19] lockdep: Fix recursive read lock related
 safe->unsafe detection
From:   Qian Cai <cai@redhat.com>
To:     Boqun Feng <boqun.feng@gmail.com>
Cc:     linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Waiman Long <longman@redhat.com>
Date:   Wed, 16 Sep 2020 17:11:59 -0400
In-Reply-To: <20200916161404.GD127490@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net>
References: <20200807074238.1632519-1-boqun.feng@gmail.com>
         <20200807074238.1632519-12-boqun.feng@gmail.com>
         <17343f6f7f2438fc376125384133c5ba70c2a681.camel@redhat.com>
         <20200916081046.GC127490@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net>
         <20200916161404.GD127490@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2020-09-17 at 00:14 +0800, Boqun Feng wrote:
> Found a way to resolve this while still keeping the BFS. Every time when
> we want to enqueue a lock_list, we basically enqueue a whole dep list of
> entries from the previous lock_list, so we can use a trick here: instead
> enqueue all the entries, we only enqueue the first entry and we can
> fetch other silbing entries with list_next_or_null_rcu(). Patch as
> below, I also took the chance to clear the code up and add more
> comments. I could see this number (in /proc/lockdep_stats):
> 
> 	max bfs queue depth:                   201
> 
> down to (after apply this patch)
> 
> 	max bfs queue depth:                   61
> 
> with x86_64_defconfig along with lockdep and selftest configs.
> 
> Qian, could you give it a try?

It works fine as the number went down from around 3000 to 500 on our workloads.