linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang3@mail.ustc.edu.cn>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Chen Huang <chenhuang5@huawei.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Darius Rad <darius@bluespec.com>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] riscv: improve unaligned memory accesses
Date: Sat, 18 Sep 2021 22:17:13 +0800	[thread overview]
Message-ID: <20210918221713.289f63bb@xhacker> (raw)
In-Reply-To: <9200c4c2-44b9-480e-6970-5188640fb00a@huawei.com>

On Sat, 18 Sep 2021 09:14:05 +0800
Kefeng Wang <wangkefeng.wang@huawei.com> wrote:

> On 2021/9/17 22:14, Jisheng Zhang wrote:
> > On Thu, 16 Sep 2021 13:08:53 +0000
> > Chen Huang <chenhuang5@huawei.com> wrote:
> >  
> >> The patchset improves RISCV unaligned memory accesses, selects
> >> HAVE_EFFICIENT_UNALIGNED_ACCESS if CPU_HAS_NO_UNALIGNED not
> >> enabled and supports DCACHE_WORD_ACCESS to improve the efficiency
> >> of unaligned memory accesses.
> >>
> >> If CPU don't support unaligned memory accesses for now, please
> >> select CONFIG_CPU_HAS_NO_UNALIGNED. For I don't know which CPU
> >> don't support unaligned memory accesses, I don't choose the
> >> CONFIG for them.  
> > This will break unified kernel Image for riscv. Obviously, we will have
> > two images for efficient unaligned access platforms and non-efficient
> > unaligned access platforms. IMHO, we may need alternative mechanism or
> > something else to dynamically enable related code path.  
> 
> it won't break unified kernel Image for riscv, if one SoC choose
> 
> CPU_HAS_NO_UNALIGNED, the single Image won't support unaligned memory

the "unified" means the kernel Image has to support all RV64GC or RV32GC SoCs.
To make the Image works for both efficient unaligned access and inefficient
unaligned access, I think we'd better make "inefficient unaligned access"
default behavior, the use alternative etc. tech to patch related code path
for efficient unaligned access.


> 
> accesses, indeed, it depends on the CONFIG, and now, arm/powerpc/m68k has

linux Distributions doesn't have enough background of which config options
must be enabled.

> 
> similar configuration.

I have little knowledge of powerpc or m68k, but there are serveral different
defconfig files for arm, for example multi_v7_defconfig and multi_v5_defconfig.
The previous v7 version enables HAVE_EFFICIENT_UNALIGNED_ACCESS while
the later v5 doesn't. Will you persuade riscv maintainers to accept one more
defconfig file?

Thanks

> 
> Yes,  it could be an optimization via alternative mechanism or something 
> else to
> 
> dynamically enable related code path later.
> 
> >
> > Regards
> >  
> >> Changes since v1:
> >>   - As Darius Rad and Jisheng Zhang mentioned, some CPUs don't support
> >>     unaligned memory accesses, add an option for CPUs to choose it or not.
> >>
> >> Chen Huang (2):
> >>    riscv: support HAVE_EFFICIENT_UNALIGNED_ACCESS
> >>    riscv: Support DCACHE_WORD_ACCESS
> >>
> >>   arch/riscv/Kconfig                      |  5 ++++
> >>   arch/riscv/include/asm/word-at-a-time.h | 37 +++++++++++++++++++++++++
> >>   2 files changed, 42 insertions(+)
> >>  
> >
> > .
> >  



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

  reply	other threads:[~2021-09-18 14:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 13:08 [PATCH v2 0/2] riscv: improve unaligned memory accesses Chen Huang
2021-09-16 13:08 ` [PATCH v2 1/2] riscv: support HAVE_EFFICIENT_UNALIGNED_ACCESS Chen Huang
2021-09-16 13:08 ` [PATCH v2 2/2] riscv: Support DCACHE_WORD_ACCESS Chen Huang
2021-09-17 14:14 ` [PATCH v2 0/2] riscv: improve unaligned memory accesses Jisheng Zhang
2021-09-18  1:14   ` Kefeng Wang
2021-09-18 14:17     ` Jisheng Zhang [this message]
2021-10-05  1:04       ` Palmer Dabbelt

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=20210918221713.289f63bb@xhacker \
    --to=jszhang3@mail.ustc.edu.cn \
    --cc=aou@eecs.berkeley.edu \
    --cc=chenhuang5@huawei.com \
    --cc=darius@bluespec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).