From: Nick Desaulniers <ndesaulniers@google.com>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
bjorn@kernel.org, Conor Dooley <conor@kernel.org>,
jszhang@kernel.org, llvm@lists.linux.dev,
Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, Arnd Bergmann <arnd@arndb.de>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 0/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Fri, 23 Jun 2023 10:17:54 -0700 [thread overview]
Message-ID: <ZJXTwqZIkXLxXaSi@google.com> (raw)
In-Reply-To: <20230622231803.GA1790165@dev-arch.thelio-3990X>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
On Thu, Jun 22, 2023 at 11:18:03PM +0000, Nathan Chancellor wrote:
> If you wanted to restrict it to just LD_IS_BFD in arch/riscv/Kconfig,
> that would be fine with me too.
>
> select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if LD_IS_BFD
Hi Jisheng, would you mind sending a v3 with the attached patch applied
on top / at the end of your series?
>
> Nick said he would work on a report for the LLVM side, so as long as
> this issue is handled in some way to avoid regressing LLD builds until
> it is resolved, I don't think there is anything else for the kernel to
> do. We like to have breadcrumbs via issue links, not sure if the report
> will be internal to Google or on LLVM's issue tracker though;
> regardless, we will have to touch this block to add a version check
> later, at which point we can add a link to the fix in LLD.
https://github.com/ClangBuiltLinux/linux/issues/1881
[-- Attachment #2: 0001-riscv-disable-DEAD_CODE_ELIMINATION-for-LLD.patch --]
[-- Type: text/x-diff, Size: 1642 bytes --]
From 3e5e010958ee41b9fb408cfade8fb017c2fe7169 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 23 Jun 2023 10:06:17 -0700
Subject: [PATCH] riscv: disable HAVE_LD_DEAD_CODE_DATA_ELIMINATION for LLD
Linking allyesconfig with ld.lld-17 with CONFIG_DEAD_CODE_ELIMINATION=y
takes hours. Assuming this is a performance regression that can be
fixed, tentatively disable this for now so that allyesconfig builds
don't start timing out. If and when there's a fix to ld.lld, this can
be converted to a version check instead so that users of older but still
supported versions of ld.lld don't hurt themselves by enabling
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y.
Link: https://github.com/ClangBuiltLinux/linux/issues/1881
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Hi Jisheng, would you mind sending a v3 with this patch on top/at the
end of your patch series?
arch/riscv/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8effe5bb7788..0573991e9b78 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -116,7 +116,8 @@ config RISCV
select HAVE_KPROBES if !XIP_KERNEL
select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
select HAVE_KRETPROBES if !XIP_KERNEL
- select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+ # https://github.com/ClangBuiltLinux/linux/issues/1881
+ select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
select HAVE_MOVE_PMD
select HAVE_MOVE_PUD
select HAVE_PCI
--
2.41.0.162.gfafddb0af9-goog
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
bjorn@kernel.org, Conor Dooley <conor@kernel.org>,
jszhang@kernel.org, llvm@lists.linux.dev,
Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, Arnd Bergmann <arnd@arndb.de>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 0/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Fri, 23 Jun 2023 10:17:54 -0700 [thread overview]
Message-ID: <ZJXTwqZIkXLxXaSi@google.com> (raw)
In-Reply-To: <20230622231803.GA1790165@dev-arch.thelio-3990X>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
On Thu, Jun 22, 2023 at 11:18:03PM +0000, Nathan Chancellor wrote:
> If you wanted to restrict it to just LD_IS_BFD in arch/riscv/Kconfig,
> that would be fine with me too.
>
> select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if LD_IS_BFD
Hi Jisheng, would you mind sending a v3 with the attached patch applied
on top / at the end of your series?
>
> Nick said he would work on a report for the LLVM side, so as long as
> this issue is handled in some way to avoid regressing LLD builds until
> it is resolved, I don't think there is anything else for the kernel to
> do. We like to have breadcrumbs via issue links, not sure if the report
> will be internal to Google or on LLVM's issue tracker though;
> regardless, we will have to touch this block to add a version check
> later, at which point we can add a link to the fix in LLD.
https://github.com/ClangBuiltLinux/linux/issues/1881
[-- Attachment #2: 0001-riscv-disable-DEAD_CODE_ELIMINATION-for-LLD.patch --]
[-- Type: text/x-diff, Size: 1642 bytes --]
From 3e5e010958ee41b9fb408cfade8fb017c2fe7169 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 23 Jun 2023 10:06:17 -0700
Subject: [PATCH] riscv: disable HAVE_LD_DEAD_CODE_DATA_ELIMINATION for LLD
Linking allyesconfig with ld.lld-17 with CONFIG_DEAD_CODE_ELIMINATION=y
takes hours. Assuming this is a performance regression that can be
fixed, tentatively disable this for now so that allyesconfig builds
don't start timing out. If and when there's a fix to ld.lld, this can
be converted to a version check instead so that users of older but still
supported versions of ld.lld don't hurt themselves by enabling
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y.
Link: https://github.com/ClangBuiltLinux/linux/issues/1881
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Hi Jisheng, would you mind sending a v3 with this patch on top/at the
end of your patch series?
arch/riscv/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8effe5bb7788..0573991e9b78 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -116,7 +116,8 @@ config RISCV
select HAVE_KPROBES if !XIP_KERNEL
select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
select HAVE_KRETPROBES if !XIP_KERNEL
- select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+ # https://github.com/ClangBuiltLinux/linux/issues/1881
+ select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
select HAVE_MOVE_PMD
select HAVE_MOVE_PUD
select HAVE_PCI
--
2.41.0.162.gfafddb0af9-goog
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-06-23 17:18 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 16:54 [PATCH v2 0/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Jisheng Zhang
2023-05-23 16:54 ` Jisheng Zhang
2023-05-23 16:54 ` [PATCH v2 1/4] riscv: move options to keep entries sorted Jisheng Zhang
2023-05-23 16:54 ` Jisheng Zhang
2023-05-25 14:01 ` Conor Dooley
2023-05-25 14:01 ` Conor Dooley
2023-06-01 4:48 ` Guo Ren
2023-06-01 4:48 ` Guo Ren
2023-05-23 16:55 ` [PATCH v2 2/4] riscv: vmlinux-xip.lds.S: remove .alternative section Jisheng Zhang
2023-05-23 16:55 ` Jisheng Zhang
2023-06-01 4:43 ` Guo Ren
2023-06-01 4:43 ` Guo Ren
2023-05-23 16:55 ` [PATCH v2 3/4] vmlinux.lds.h: use correct .init.data.* section name Jisheng Zhang
2023-05-23 16:55 ` Jisheng Zhang
2023-05-24 11:02 ` Kefeng Wang
2023-05-24 11:02 ` Kefeng Wang
2023-05-23 16:55 ` [PATCH v2 4/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Jisheng Zhang
2023-05-23 16:55 ` Jisheng Zhang
2023-05-24 11:04 ` Kefeng Wang
2023-05-24 11:04 ` Kefeng Wang
2023-06-14 14:49 ` [PATCH v2 0/4] " Palmer Dabbelt
2023-06-14 14:49 ` Palmer Dabbelt
2023-06-14 16:25 ` Jisheng Zhang
2023-06-14 16:25 ` Jisheng Zhang
2023-06-15 13:54 ` Palmer Dabbelt
2023-06-15 13:54 ` Palmer Dabbelt
2023-06-19 22:06 ` Palmer Dabbelt
2023-06-19 22:06 ` Palmer Dabbelt
2023-06-20 20:05 ` Nick Desaulniers
2023-06-20 20:05 ` Nick Desaulniers
2023-06-20 20:13 ` Conor Dooley
2023-06-20 20:13 ` Conor Dooley
2023-06-20 20:32 ` Nick Desaulniers
2023-06-20 20:32 ` Nick Desaulniers
2023-06-20 20:41 ` Palmer Dabbelt
2023-06-20 20:41 ` Palmer Dabbelt
2023-06-20 20:47 ` Nick Desaulniers
2023-06-20 20:47 ` Nick Desaulniers
2023-06-20 21:08 ` Palmer Dabbelt
2023-06-20 21:08 ` Palmer Dabbelt
2023-06-21 0:13 ` Palmer Dabbelt
2023-06-21 0:13 ` Palmer Dabbelt
2023-06-21 14:53 ` Palmer Dabbelt
2023-06-21 14:53 ` Palmer Dabbelt
2023-06-21 16:42 ` Conor Dooley
2023-06-21 16:42 ` Conor Dooley
2023-06-21 17:23 ` Conor Dooley
2023-06-21 17:23 ` Conor Dooley
2023-06-21 17:51 ` Björn Töpel
2023-06-21 17:51 ` Björn Töpel
2023-06-21 18:19 ` Palmer Dabbelt
2023-06-21 18:19 ` Palmer Dabbelt
2023-06-21 19:46 ` Palmer Dabbelt
2023-06-21 19:46 ` Palmer Dabbelt
2023-06-22 21:40 ` Nick Desaulniers
2023-06-22 21:40 ` Nick Desaulniers
2023-06-22 21:42 ` Palmer Dabbelt
2023-06-22 21:42 ` Palmer Dabbelt
2023-06-22 21:53 ` Nathan Chancellor
2023-06-22 21:53 ` Nathan Chancellor
2023-06-22 22:16 ` Palmer Dabbelt
2023-06-22 22:16 ` Palmer Dabbelt
2023-06-22 23:18 ` Nathan Chancellor
2023-06-22 23:18 ` Nathan Chancellor
2023-06-23 17:17 ` Nick Desaulniers [this message]
2023-06-23 17:17 ` Nick Desaulniers
2023-06-25 12:24 ` Jisheng Zhang
2023-06-25 12:24 ` Jisheng Zhang
2023-06-25 12:43 ` Conor Dooley
2023-06-25 12:43 ` Conor Dooley
2023-06-25 20:05 ` Palmer Dabbelt
2023-06-25 20:05 ` Palmer Dabbelt
2023-06-25 20:06 ` Palmer Dabbelt
2023-06-25 20:06 ` Palmer Dabbelt
2023-06-25 20:05 ` Palmer Dabbelt
2023-07-22 0:37 ` Fangrui Song
2023-07-22 0:37 ` Fangrui Song
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=ZJXTwqZIkXLxXaSi@google.com \
--to=ndesaulniers@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=bjorn@kernel.org \
--cc=conor@kernel.org \
--cc=jszhang@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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 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.