All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	bjorn@kernel.org, Conor Dooley <conor@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: Sun, 25 Jun 2023 20:24:56 +0800	[thread overview]
Message-ID: <ZJgyGD8ZSjVmiprB@xhacker> (raw)
In-Reply-To: <ZJXTwqZIkXLxXaSi@google.com>

On Fri, Jun 23, 2023 at 10:17:54AM -0700, Nick Desaulniers wrote:
> 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?

Hi Nick, Nathan, Palmer,

I saw the series has been applied to riscv-next, so I'm not sure which
solution would it be, Palmer to apply Nick's patch to riscv-next or
I to send out v3, any suggestion is appreciated.

Thanks
> 
> > 
> > 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

> 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: Jisheng Zhang <jszhang@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	bjorn@kernel.org, Conor Dooley <conor@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: Sun, 25 Jun 2023 20:24:56 +0800	[thread overview]
Message-ID: <ZJgyGD8ZSjVmiprB@xhacker> (raw)
In-Reply-To: <ZJXTwqZIkXLxXaSi@google.com>

On Fri, Jun 23, 2023 at 10:17:54AM -0700, Nick Desaulniers wrote:
> 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?

Hi Nick, Nathan, Palmer,

I saw the series has been applied to riscv-next, so I'm not sure which
solution would it be, Palmer to apply Nick's patch to riscv-next or
I to send out v3, any suggestion is appreciated.

Thanks
> 
> > 
> > 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

> 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
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-06-25 12:36 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
2023-06-23 17:17                                       ` Nick Desaulniers
2023-06-25 12:24                                       ` Jisheng Zhang [this message]
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=ZJgyGD8ZSjVmiprB@xhacker \
    --to=jszhang@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=bjorn@kernel.org \
    --cc=conor@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=ndesaulniers@google.com \
    --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.