From: Christoph Hellwig <hch@infradead.org>
To: Alan Kao <alankao@andestech.com>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@sifive.com>, Albert Ou <albert@sifive.com>,
Christoph Hellwig <hch@infradead.org>,
Andrew Waterman <andrew@sifive.com>,
Arnd Bergmann <arnd@arndb.de>, Darius Rad <darius@bluespec.com>,
Vincent Chen <vincentc@andestech.com>,
Zong Li <zong@andestech.com>, Nick Hu <nickhu@andestech.com>,
Greentime Hu <greentime@andestech.com>
Subject: Re: [PATCH v4 5/5] Auto-detect whether a FPU exists
Date: Wed, 8 Aug 2018 00:18:54 -0700 [thread overview]
Message-ID: <20180808071854.GB27402@infradead.org> (raw)
In-Reply-To: <1533698685-18022-6-git-send-email-alankao@andestech.com>
> extern unsigned long elf_hwcap;
> +#ifdef CONFIG_FPU
> +extern bool no_fpu;
> +#endif
No need to have an ifdef around an extern declaration.
> static inline void fstate_save(struct task_struct *task,
> struct pt_regs *regs)
> {
> + if (unlikely(no_fpu))
> + return;
> +
> if ((regs->sstatus & SR_FS) == SR_FS_DIRTY) {
Wouldn't the sstatus check here always evaluate to false for the
no_fpu case anyway?
> @@ -39,6 +43,9 @@ static inline void fstate_save(struct task_struct *task,
> static inline void fstate_restore(struct task_struct *task,
> struct pt_regs *regs)
> {
> + if (unlikely(no_fpu))
> + return;
> +
Same here?
> -#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
> +#define DEFAULT_SSTATUS \
> + ((unlikely(no_fpu)) ? (SR_SPIE | SR_FS_OFF) : (SR_SPIE | SR_FS_INITIAL))
Please don't hide this in a a macro.
I'd rather get rid of the macro and do this in start_thread:
regs->sstatus = SR_SPIE /* User mode, irqs on */
if (!no_fpu)
regs->sstatus |= SR_FS_INITIAL;
and provide a stub for the no_fpu variable for the !CONFIG_CPU case.
In fact I'd probably invert the polarity of this variable and make it
'has_fpu'. The for !CONFIG_FPU you define that as
#define has_cpu false
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -22,6 +22,9 @@
> #include <asm/hwcap.h>
>
> unsigned long elf_hwcap __read_mostly;
> +#ifdef CONFIG_FPU
> +bool no_fpu __read_mostly;
> +#endif
>
> void riscv_fill_hwcap(void)
> {
> @@ -58,4 +61,12 @@ void riscv_fill_hwcap(void)
> elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
>
> pr_info("elf_hwcap is 0x%lx", elf_hwcap);
> +
> +#ifdef CONFIG_FPU
> + no_fpu = 0;
> + if (!(elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))) {
> + pr_info("Bypass FPU code.");
> + no_fpu = 1;
> + }
> +#endif
Note that variables unless they are on stack in a function are always
initialized to zero. So together with my above ideas this could become:
#ifdef CONFIG_FPU
if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)
has_fpu = true;
#endif
Note the use of true/false for booleans and dropping the printk.
> diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
> index 2450b824d799..9714e4fccb69 100644
> --- a/arch/riscv/kernel/signal.c
> +++ b/arch/riscv/kernel/signal.c
> @@ -45,6 +45,9 @@ static long restore_fp_state(struct pt_regs *regs,
> struct __riscv_d_ext_state __user *state = &sc_fpregs->d;
> size_t i;
>
> + if (unlikely(no_fpu))
> + return 0;
I'd be tempted to move this into the caler, e.g.
if (has_fpu) {
restore_fp_state()..
}
Also the unlikely annotations seem odd - this seems like something that
even the simplest branch predictor can handle. If we really want to
optimize it (not for this series but in the future) we should implement
the alternatives mechanism for live patching.
next prev parent reply other threads:[~2018-08-08 7:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 3:24 [PATCH v4 0/5] riscv: Add support to no-FPU systems Alan Kao
2018-08-08 3:24 ` [PATCH v4 1/5] Extract FPU context operations from entry.S Alan Kao
2018-08-08 3:24 ` [PATCH v4 2/5] Refactor FPU code in signal setup/return procedures Alan Kao
2018-08-08 3:24 ` [PATCH v4 3/5] Cleanup ISA string setting Alan Kao
2018-08-20 22:22 ` Palmer Dabbelt
2018-08-21 2:47 ` Alan Kao
2018-08-21 19:36 ` Palmer Dabbelt
2018-08-08 3:24 ` [PATCH v4 4/5] Allow to disable FPU support Alan Kao
2018-08-08 7:07 ` Christoph Hellwig
2018-08-08 3:24 ` [PATCH v4 5/5] Auto-detect whether a FPU exists Alan Kao
2018-08-08 7:18 ` Christoph Hellwig [this message]
2018-08-20 22:22 ` [PATCH v4 0/5] riscv: Add support to no-FPU systems Palmer Dabbelt
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=20180808071854.GB27402@infradead.org \
--to=hch@infradead.org \
--cc=alankao@andestech.com \
--cc=albert@sifive.com \
--cc=andrew@sifive.com \
--cc=arnd@arndb.de \
--cc=darius@bluespec.com \
--cc=greentime@andestech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=nickhu@andestech.com \
--cc=palmer@sifive.com \
--cc=vincentc@andestech.com \
--cc=zong@andestech.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
all inboxes | Powered by JetHome®