From: Waiman Long <llong@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Boqun Feng <boqun.feng@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] locking/lockdep: Disable KASAN instrumentation of lockdep.c
Date: Fri, 31 Jan 2025 16:47:06 -0500 [thread overview]
Message-ID: <14eb5880-7df1-4717-8f6e-e667328c369d@redhat.com> (raw)
In-Reply-To: <20250131165020.878944-1-longman@redhat.com>
On 1/31/25 11:50 AM, Waiman Long wrote:
> Both KASAN and LOCKDEP are commonly enabled in building a debug kernel.
> Each of them can significantly slow down the speed of a debug kernel.
> Enabling KASAN instrumentation of the LOCKDEP code will further slow
> thing down.
>
> Since LOCKDEP is a high overhead debugging tool, it will never get
> enabled in a production kernel. The LOCKDEP code is also pretty mature
> and is unlikely to get major changes. There is also a possibility of
> recursion similar to KCSAN. As the small advantage of enabling KASAN
> instrumentation to catch potential memory access error is probably
> not worth the drawback of further slowing down a debug kernel, disable
> KASAN instrumentation to enable a debug kernel to gain a little bit of
> speed back.
>
> With a debug kernel with both LOCKDEP and KASAN enabled running on a
> 2-socket 144-thread system, the time to do a "make -j144" kernel build
> was 18m40.641s. After applying this patch, the parallel kernel build
> time was reduced to 17m35.136s. This is a reduction of about 66s (5.8%).
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/locking/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
> index 0db4093d17b8..8a588b0227b1 100644
> --- a/kernel/locking/Makefile
> +++ b/kernel/locking/Makefile
> @@ -6,6 +6,7 @@ KCOV_INSTRUMENT := n
> obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o
>
> # Avoid recursion lockdep -> sanitizer -> ... -> lockdep.
> +KASAN_SANITIZE_lockdep.o := n
> KCSAN_SANITIZE_lockdep.o := n
>
> ifdef CONFIG_FUNCTION_TRACER
The rationale behind this patch is due to the fact that a similar
configured PREEMPT_RT debug kernel is found to be about 3 times slower
than the non-RT debug kernel. For the test same system, the parallel
build runtime is 59m56.722s. After applying this patch, it is reduced to
38m3.348s. Its more than 1/3 reduction is more than I would have
expected. So the lockdep code is much more heavily used in a PREEMPT_RT
debug kernel.
Cheers,
Longman
next prev parent reply other threads:[~2025-01-31 21:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 16:50 [PATCH] locking/lockdep: Disable KASAN instrumentation of lockdep.c Waiman Long
2025-01-31 21:47 ` Waiman Long [this message]
2025-02-03 11:24 ` Peter Zijlstra
2025-02-03 14:11 ` Waiman Long
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=14eb5880-7df1-4717-8f6e-e667328c369d@redhat.com \
--to=llong@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox