linux-kernel - RE: [PATCH v4 1/2] RISC-V: Probe for unaligned access speed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <de95229a14614198894a8ce421c30d94@AcuMS.aculab.com>
Date:   Thu, 14 Sep 2023 08:46:54 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Geert Uytterhoeven' <geert@...ux-m68k.org>,
        Evan Green <evan@...osinc.com>
CC:     Palmer Dabbelt <palmer@...osinc.com>,
        Heiko Stuebner <heiko@...ech.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Björn Töpel <bjorn@...osinc.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Guo Ren <guoren@...nel.org>,
        Jisheng Zhang <jszhang@...nel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Jonathan Corbet <corbet@....net>,
        "Sia Jee Heng" <jeeheng.sia@...rfivetech.com>,
        Marc Zyngier <maz@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Greentime Hu <greentime.hu@...ive.com>,
        Simon Hosie <shosie@...osinc.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        "Alexandre Ghiti" <alexghiti@...osinc.com>,
        Ley Foon Tan <leyfoon.tan@...rfivetech.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Anup Patel <apatel@...tanamicro.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Xianting Tian <xianting.tian@...ux.alibaba.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        "Andy Chiu" <andy.chiu@...ive.com>
Subject: RE: [PATCH v4 1/2] RISC-V: Probe for unaligned access speed

From: Geert Uytterhoeven
> Sent: 14 September 2023 08:33
...
> > >     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)

Would that match zero overhead unless the access crosses a
cache line boundary?
(I can't remember whether the test is using increasing addresses.)

...
> > >     vexriscv/orangecrab:
> > >
> > >         cpu0: 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.00417,
> unaligned accesses are slow
> 
> > > I am a bit surprised by the near-zero values.  Are these expected?
> >
> > This could be expected, if firmware is trapping the unaligned accesses
> > and coming out >100x slower than a native access. If you're interested
> > in getting a little more resolution, you could try to print a few more
> > decimal places with something like (sorry gmail mangles the whitespace
> > on this):

I'd expect one of three possible values:
- 1.0x: Basically zero cost except for cache line/page boundaries.
- ~2: Hardware does two reads and merges the values.
- >100: Trap fixed up in software.

I'd think the '2' case could be considered fast.
You only need to time one access to see if it was a fault.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)