Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-108-ge995779fee-fm-20230203.001-ge995779f
Mime-Version: 1.0
Message-Id: <b9f274ad-591b-40b5-9441-a45fe67b5b8d@app.fastmail.com>
In-Reply-To: <3b17d229-bad4-e6a0-9055-c585dd5a62e4@loongson.cn>
References: <20230202084238.2408516-1-chenhuacai@loongson.cn>
 <5fc85453-1e2c-1f00-7879-1b5fa318c78a@xen0n.name>
 <5303aeda-5c66-ede6-b3ac-7d8ebd73ec70@loongson.cn>
 <b1809500e4d55564a1084a3014fb9603ba3d1438.camel@xry111.site>
 <3b17d229-bad4-e6a0-9055-c585dd5a62e4@loongson.cn>
Date:   Mon, 06 Feb 2023 14:22:17 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Jianmin Lv" <lvjianmin@loongson.cn>,
        "Xi Ruoyao" <xry111@xry111.site>,
        "WANG Xuerui" <kernel@xen0n.name>,
        "Huacai Chen" <chenhuacai@loongson.cn>,
        "Huacai Chen" <chenhuacai@kernel.org>
Cc:     loongarch@lists.linux.dev, Linux-Arch <linux-arch@vger.kernel.org>,
        "Xuefeng Li" <lixuefeng@loongson.cn>, guoren <guoren@kernel.org>,
        "Jiaxun Yang" <jiaxun.yang@flygoat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] LoongArch: Make -mstrict-align be configurable
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Feb 6, 2023, at 14:13, Jianmin Lv wrote:
> On 2023/2/6 =E4=B8=8B=E5=8D=887:18, Xi Ruoyao wrote:
>> On Mon, 2023-02-06 at 18:24 +0800, Jianmin Lv wrote:
>>> Hi, Xuerui
>>>
>>> I think the kernels produced with and without -mstrict-align have ma=
inly
>>> following differences:
>>> - Diffirent size. I build two kernls (vmlinux), size of kernel with
>>> -mstrict-align is 26533376 bytes and size of kernel without
>>> -mstrict-align is 26123280 bytes.
>>> - Diffirent performance. For example, in kernel function jhash(), the
>>> assemble code slices with and without -mstrict-align are following:
>>=20
>> But there are still questions remaining:
>>=20
>> (1) Is the difference contributed by a bad code generation of GCC?  If
>> true, it's better to improve GCC before someone starts to build a dis=
tro
>> for LA264 as it would benefit the user space as well.
>>=20
> AFAIK, GCC builds to produce unaligned-access-enabled target binary by=20
> default (without -mstrict-align) for improving user space performance=20
> (small size and runtime high performance), which is also based the fac=
t=20
> that the vast majority of LoongArch CPUs support unaligned-access.
>
>> (2) Is there some "big bad unaligned access loop" on a hot spot in the
>> kernel code?  If true, it may be better to just refactor the C code
>> because doing so will benefit all ports, not only LoongArch.  Otherwi=
se,
>> it may be unworthy to optimize for some cold paths.
>>=20
> Frankly, I'm not sure if there is this kind of hot code in kernel, I=20
> just see the difference from different kernel size and different=20
> assemble code slice. And I'm afraid that it may be difficult to judge=20
> whether it is reasonable hot code or not if exists.

Just look for CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, this will
show you code locations that use different implementations based on
whether the kernel should run on CPUs without unaligned access or
not.

      Arnd