All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Evan Green <evan@rivosinc.com>
Cc: "Palmer Dabbelt" <palmer@rivosinc.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-doc@vger.kernel.org, "Björn Töpel" <bjorn@rivosinc.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Guo Ren" <guoren@kernel.org>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	linux-riscv@lists.infradead.org,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sia Jee Heng" <jeeheng.sia@starfivetech.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Greentime Hu" <greentime.hu@sifive.com>,
	"Simon Hosie" <shosie@rivosinc.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Ley Foon Tan" <leyfoon.tan@starfivetech.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Anup Patel" <apatel@ventanamicro.com>,
	linux-kernel@vger.kernel.org,
	"Xianting Tian" <xianting.tian@linux.alibaba.com>,
	"David Laight" <David.Laight@aculab.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Andy Chiu" <andy.chiu@sifive.com>
Subject: Re: [PATCH v4 1/2] RISC-V: Probe for unaligned access speed
Date: Wed, 13 Sep 2023 14:36:27 +0200	[thread overview]
Message-ID: <CAMuHMdVtXGjP8VFMiv-7OMFz1XvfU1cz=Fw4jL3fcp4wO1etzQ@mail.gmail.com> (raw)
In-Reply-To: <20230818194136.4084400-2-evan@rivosinc.com>

Hi Evan,

On Fri, Aug 18, 2023 at 9:44 PM Evan Green <evan@rivosinc.com> wrote:
> Rather than deferring unaligned access speed determinations to a vendor
> function, let's probe them and find out how fast they are. If we
> determine that an unaligned word access is faster than N byte accesses,
> mark the hardware's unaligned access as "fast". Otherwise, we mark
> accesses as slow.
>
> The algorithm itself runs for a fixed amount of jiffies. Within each
> iteration it attempts to time a single loop, and then keeps only the best
> (fastest) loop it saw. This algorithm was found to have lower variance from
> run to run than my first attempt, which counted the total number of
> iterations that could be done in that fixed amount of jiffies. By taking
> only the best iteration in the loop, assuming at least one loop wasn't
> perturbed by an interrupt, we eliminate the effects of interrupts and
> other "warm up" factors like branch prediction. The only downside is it
> depends on having an rdtime granular and accurate enough to measure a
> single copy. If we ever manage to complete a loop in 0 rdtime ticks, we
> leave the unaligned setting at UNKNOWN.
>
> There is a slight change in user-visible behavior here. Previously, all
> boards except the THead C906 reported misaligned access speed of
> UNKNOWN. C906 reported FAST. With this change, since we're now measuring
> misaligned access speed on each hart, all RISC-V systems will have this
> key set as either FAST or SLOW.
>
> Currently, we don't have a way to confidently measure the difference between
> SLOW and EMULATED, so we label anything not fast as SLOW. This will
> mislabel some systems that are actually EMULATED as SLOW. When we get
> support for delegating misaligned access traps to the kernel (as opposed
> to the firmware quietly handling it), we can explicitly test in Linux to
> see if unaligned accesses trap. Those systems will start to report
> EMULATED, though older (today's) systems without that new SBI mechanism
> will continue to report SLOW.
>
> I've updated the documentation for those hwprobe values to reflect
> this, specifically: SLOW may or may not be emulated by software, and FAST
> represents means being faster than equivalent byte accesses. The change
> in documentation is accurate with respect to both the former and current
> behavior.
>
> Signed-off-by: Evan Green <evan@rivosinc.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks for your patch, which is now commit 584ea6564bcaead2 ("RISC-V:
Probe for unaligned access speed") in v6.6-rc1.

On the boards I have, I get:

    rzfive:
        cpu0: Ratio of byte access time to unaligned word access is
1.05, unaligned accesses are fast

    icicle:

        cpu1: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow
        cpu2: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow
        cpu3: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

        cpu0: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

    k210:

        cpu1: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow
        cpu0: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow

    starlight:

        cpu1: Ratio of byte access time to unaligned word access is
0.01, unaligned accesses are slow
        cpu0: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow

    vexriscv/orangecrab:

        cpu0: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

I am a bit surprised by the near-zero values.  Are these expected?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Evan Green <evan@rivosinc.com>
Cc: "Palmer Dabbelt" <palmer@rivosinc.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-doc@vger.kernel.org, "Björn Töpel" <bjorn@rivosinc.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Guo Ren" <guoren@kernel.org>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	linux-riscv@lists.infradead.org,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sia Jee Heng" <jeeheng.sia@starfivetech.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Greentime Hu" <greentime.hu@sifive.com>,
	"Simon Hosie" <shosie@rivosinc.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Ley Foon Tan" <leyfoon.tan@starfivetech.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Anup Patel" <apatel@ventanamicro.com>,
	linux-kernel@vger.kernel.org,
	"Xianting Tian" <xianting.tian@linux.alibaba.com>,
	"David Laight" <David.Laight@aculab.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Andy Chiu" <andy.chiu@sifive.com>
Subject: Re: [PATCH v4 1/2] RISC-V: Probe for unaligned access speed
Date: Wed, 13 Sep 2023 14:36:27 +0200	[thread overview]
Message-ID: <CAMuHMdVtXGjP8VFMiv-7OMFz1XvfU1cz=Fw4jL3fcp4wO1etzQ@mail.gmail.com> (raw)
In-Reply-To: <20230818194136.4084400-2-evan@rivosinc.com>

Hi Evan,

On Fri, Aug 18, 2023 at 9:44 PM Evan Green <evan@rivosinc.com> wrote:
> Rather than deferring unaligned access speed determinations to a vendor
> function, let's probe them and find out how fast they are. If we
> determine that an unaligned word access is faster than N byte accesses,
> mark the hardware's unaligned access as "fast". Otherwise, we mark
> accesses as slow.
>
> The algorithm itself runs for a fixed amount of jiffies. Within each
> iteration it attempts to time a single loop, and then keeps only the best
> (fastest) loop it saw. This algorithm was found to have lower variance from
> run to run than my first attempt, which counted the total number of
> iterations that could be done in that fixed amount of jiffies. By taking
> only the best iteration in the loop, assuming at least one loop wasn't
> perturbed by an interrupt, we eliminate the effects of interrupts and
> other "warm up" factors like branch prediction. The only downside is it
> depends on having an rdtime granular and accurate enough to measure a
> single copy. If we ever manage to complete a loop in 0 rdtime ticks, we
> leave the unaligned setting at UNKNOWN.
>
> There is a slight change in user-visible behavior here. Previously, all
> boards except the THead C906 reported misaligned access speed of
> UNKNOWN. C906 reported FAST. With this change, since we're now measuring
> misaligned access speed on each hart, all RISC-V systems will have this
> key set as either FAST or SLOW.
>
> Currently, we don't have a way to confidently measure the difference between
> SLOW and EMULATED, so we label anything not fast as SLOW. This will
> mislabel some systems that are actually EMULATED as SLOW. When we get
> support for delegating misaligned access traps to the kernel (as opposed
> to the firmware quietly handling it), we can explicitly test in Linux to
> see if unaligned accesses trap. Those systems will start to report
> EMULATED, though older (today's) systems without that new SBI mechanism
> will continue to report SLOW.
>
> I've updated the documentation for those hwprobe values to reflect
> this, specifically: SLOW may or may not be emulated by software, and FAST
> represents means being faster than equivalent byte accesses. The change
> in documentation is accurate with respect to both the former and current
> behavior.
>
> Signed-off-by: Evan Green <evan@rivosinc.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks for your patch, which is now commit 584ea6564bcaead2 ("RISC-V:
Probe for unaligned access speed") in v6.6-rc1.

On the boards I have, I get:

    rzfive:
        cpu0: Ratio of byte access time to unaligned word access is
1.05, unaligned accesses are fast

    icicle:

        cpu1: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow
        cpu2: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow
        cpu3: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

        cpu0: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

    k210:

        cpu1: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow
        cpu0: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow

    starlight:

        cpu1: Ratio of byte access time to unaligned word access is
0.01, unaligned accesses are slow
        cpu0: Ratio of byte access time to unaligned word access is
0.02, unaligned accesses are slow

    vexriscv/orangecrab:

        cpu0: Ratio of byte access time to unaligned word access is
0.00, unaligned accesses are slow

I am a bit surprised by the near-zero values.  Are these expected?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

  reply	other threads:[~2023-09-13 12:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-18 19:41 [PATCH v4 0/2] RISC-V: Probe for misaligned access speed Evan Green
2023-08-18 19:41 ` Evan Green
2023-08-18 19:41 ` [PATCH v4 1/2] RISC-V: Probe for unaligned " Evan Green
2023-08-18 19:41   ` Evan Green
2023-09-13 12:36   ` Geert Uytterhoeven [this message]
2023-09-13 12:36     ` Geert Uytterhoeven
2023-09-13 17:46     ` Evan Green
2023-09-13 17:46       ` Evan Green
2023-09-14  7:32       ` Geert Uytterhoeven
2023-09-14  7:32         ` Geert Uytterhoeven
2023-09-14  8:46         ` David Laight
2023-09-14  8:46           ` David Laight
2023-09-14 15:01           ` Evan Green
2023-09-14 15:01             ` Evan Green
2023-09-14 15:55             ` David Laight
2023-09-14 15:55               ` David Laight
2023-09-14 16:36               ` Evan Green
2023-09-14 16:36                 ` Evan Green
2023-09-15  7:57                 ` David Laight
2023-09-15  7:57                   ` David Laight
2023-09-15 16:47                   ` Evan Green
2023-09-15 16:47                     ` Evan Green
2023-10-19  6:37         ` Geert Uytterhoeven
2023-10-19  6:37           ` Geert Uytterhoeven
2023-10-19  7:51           ` Lad, Prabhakar
2023-10-19  7:51             ` Lad, Prabhakar
2023-08-18 19:41 ` [PATCH v4 2/2] RISC-V: alternative: Remove feature_probe_func Evan Green
2023-08-18 19:41   ` Evan Green
2023-08-30 20:30 ` [PATCH v4 0/2] RISC-V: Probe for misaligned access speed patchwork-bot+linux-riscv
2023-08-30 20:30   ` patchwork-bot+linux-riscv

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='CAMuHMdVtXGjP8VFMiv-7OMFz1XvfU1cz=Fw4jL3fcp4wO1etzQ@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=David.Laight@aculab.com \
    --cc=ajones@ventanamicro.com \
    --cc=alexghiti@rivosinc.com \
    --cc=andy.chiu@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=bjorn@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=corbet@lwn.net \
    --cc=evan@rivosinc.com \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=jeeheng.sia@starfivetech.com \
    --cc=jszhang@kernel.org \
    --cc=leyfoon.tan@starfivetech.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=masahiroy@kernel.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=shosie@rivosinc.com \
    --cc=xianting.tian@linux.alibaba.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.