Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Yangyu Chen' <cyy@cyyself.name>,
        "evan@rivosinc.com" <evan@rivosinc.com>
CC:     "ajones@ventanamicro.com" <ajones@ventanamicro.com>,
        "alexghiti@rivosinc.com" <alexghiti@rivosinc.com>,
        "andy.chiu@sifive.com" <andy.chiu@sifive.com>,
        "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
        "apatel@ventanamicro.com" <apatel@ventanamicro.com>,
        "conor.dooley@microchip.com" <conor.dooley@microchip.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "greentime.hu@sifive.com" <greentime.hu@sifive.com>,
        "guoren@kernel.org" <guoren@kernel.org>,
        "heiko.stuebner@vrull.eu" <heiko.stuebner@vrull.eu>,
        "heiko@sntech.de" <heiko@sntech.de>,
        "jeeheng.sia@starfivetech.com" <jeeheng.sia@starfivetech.com>,
        "jszhang@kernel.org" <jszhang@kernel.org>,
        "leyfoon.tan@starfivetech.com" <leyfoon.tan@starfivetech.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        "lizhengyu3@huawei.com" <lizhengyu3@huawei.com>,
        "masahiroy@kernel.org" <masahiroy@kernel.org>,
        "palmer@dabbelt.com" <palmer@dabbelt.com>,
        "palmer@rivosinc.com" <palmer@rivosinc.com>,
        "paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
        "rdunlap@infradead.org" <rdunlap@infradead.org>,
        "samuel@sholland.org" <samuel@sholland.org>,
        "shosie@rivosinc.com" <shosie@rivosinc.com>,
        "sunilvl@ventanamicro.com" <sunilvl@ventanamicro.com>,
        "xianting.tian@linux.alibaba.com" <xianting.tian@linux.alibaba.com>
Subject: RE: [PATCH 0/2] RISC-V: Probe for misaligned access speed
Thread-Topic: [PATCH 0/2] RISC-V: Probe for misaligned access speed
Thread-Index: AQHZpoXPPuZN4PqkvUikwrb+zgw4aa+c0l/Q
Date:   Mon, 26 Jun 2023 09:24:36 +0000
Message-ID: <253bad9e83cd4890b29dd89a3d5a1937@AcuMS.aculab.com>
References: <20230623222016.3742145-1-evan@rivosinc.com>
 <tencent_817CE182DEDA938E03B848314821098D4408@qq.com>
In-Reply-To: <tencent_817CE182DEDA938E03B848314821098D4408@qq.com>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: Yangyu Chen
> Sent: 24 June 2023 11:22
> 
> Hi,
> 
> Thanks for doing this.
> 
> On 6/24/23 6:20 AM, Evan Green wrote:
> > I don't have a machine where misaligned accesses are slow, but I'd be
> > interested to see the results of booting this series if someone did.
> 
> I have tested your patches on a 100MHz BigCore rocket-chip with opensbi running on FPGA with
> 72bit(64bit+ECC) DDR3 1600MHz memory. As the rocket-chip did not support misaligned memory access,
> every misaligned memory access will trap and emulated by SBI.
> 
> Here is the result:
...
> ~ # dmesg | grep Unaligned
> [    0.210140] cpu1: Unaligned word copy 0 MB/s, byte copy 38 MB/s, misaligned accesses are slow
> [    0.410715] cpu0: Unaligned word copy 0 MB/s, byte copy 35 MB/s, misaligned accesses are slow

How many misaligned cycles are in the test loop?
If emulated ones are that slow you pretty much only need to test one.

Also it is pretty clear that you really don't want to be emulating them.
If the emulation is hidden from the kernel that really doesn't help at all.

	David

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