lkml.org 
[lkml]   [2023]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 1/2] RISC-V: Probe for unaligned access speed
    Hi Geert,

    On Thu, Oct 19, 2023 at 7:40 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    >
    > Hi Prabahkar,
    >
    > On Thu, Sep 14, 2023 at 9:32 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    > > On Wed, Sep 13, 2023 at 7:46 PM Evan Green <evan@rivosinc.com> wrote:
    > > > On Wed, Sep 13, 2023 at 5:36 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    > > > > 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
    > > >
    > > > Hrm, I'm a little surprised to be seeing this number come out so close
    > > > to 1. If you reboot a few times, what kind of variance do you get on
    > > > this?
    > >
    > > Rock-solid at 1.05 (even with increased resolution: 1.05853 on 3 tries)
    >
    > After upgrading the firmware from [1] to [2], this changed to
    > "0.00, unaligned accesses are slow".
    >
    > [1] RZ-Five-ETH
    > U-Boot 2020.10-g611c657e43 (Aug 26 2022 - 11:29:06 +0100)
    >
    > [2] OpenSBI v1.3-75-g3cf0ea4
    > U-Boot 2023.01-00209-g1804c8ab17 (Oct 04 2023 - 13:18:01 +0100)
    >
    Thanks, let me go through the changes.

    Cheers,
    Prabhakar

    \
     
     \ /
      Last update: 2023-10-19 11:19    [W:4.126 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site