All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atish Patra <atishp@atishpatra.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Atish Patra <Atish.Patra@wdc.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Nick Kossifidis <mick@ics.forth.gr>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>, Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32
Date: Thu, 14 Jan 2021 10:33:01 -0800	[thread overview]
Message-ID: <CAOnJCU+mCPwbeOQpmHmu3ar_17otmgftiKHLL+Z4_nExpj0=cA@mail.gmail.com> (raw)
In-Reply-To: <mhng-1400a3dd-651b-4a78-bb2d-1f10580add75@palmerdabbelt-glaptop>

On Wed, Jan 13, 2021 at 9:10 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote:
> > SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
> > 64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
> > allocation if it is requested to be aligned with SMP_CACHE_BYTES.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > ---
> >  arch/riscv/include/asm/cache.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
> > index 9b58b104559e..c9c669ea2fe6 100644
> > --- a/arch/riscv/include/asm/cache.h
> > +++ b/arch/riscv/include/asm/cache.h
> > @@ -7,7 +7,11 @@
> >  #ifndef _ASM_RISCV_CACHE_H
> >  #define _ASM_RISCV_CACHE_H
> >
> > +#ifdef CONFIG_64BIT
> >  #define L1_CACHE_SHIFT               6
> > +#else
> > +#define L1_CACHE_SHIFT               5
> > +#endif
> >
> >  #define L1_CACHE_BYTES               (1 << L1_CACHE_SHIFT)
>
> Should we not instead just
>
> #define SMP_CACHE_BYTES L1_CACHE_BYTES
>
> like a handful of architectures do?
>

The generic code already defines it that way in include/linux/cache.h

> The cache size is sort of fake here, as we don't have any non-coherent
> mechanisms, but IIRC we wrote somewhere that it's recommended to have 64-byte
> cache lines in RISC-V implementations as software may assume that for
> performance reasons.  Not really a strong reason, but I'd prefer to just make
> these match.
>

If it is documented somewhere in the kernel, we should update that. I
think SMP_CACHE_BYTES being 64
actually degrades the performance as there will be a fragmented memory
blocks with 32 bit bytes gap wherever
SMP_CACHE_BYTES is used as an alignment requirement.

In addition to that, Geert Uytterhoeven mentioned some panic on vex32
without this patch.
I didn't see anything in Qemu though.


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



-- 
Regards,
Atish

WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atishp@atishpatra.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Atish Patra <Atish.Patra@wdc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Nick Kossifidis <mick@ics.forth.gr>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32
Date: Thu, 14 Jan 2021 10:33:01 -0800	[thread overview]
Message-ID: <CAOnJCU+mCPwbeOQpmHmu3ar_17otmgftiKHLL+Z4_nExpj0=cA@mail.gmail.com> (raw)
In-Reply-To: <mhng-1400a3dd-651b-4a78-bb2d-1f10580add75@palmerdabbelt-glaptop>

On Wed, Jan 13, 2021 at 9:10 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote:
> > SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
> > 64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
> > allocation if it is requested to be aligned with SMP_CACHE_BYTES.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > ---
> >  arch/riscv/include/asm/cache.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
> > index 9b58b104559e..c9c669ea2fe6 100644
> > --- a/arch/riscv/include/asm/cache.h
> > +++ b/arch/riscv/include/asm/cache.h
> > @@ -7,7 +7,11 @@
> >  #ifndef _ASM_RISCV_CACHE_H
> >  #define _ASM_RISCV_CACHE_H
> >
> > +#ifdef CONFIG_64BIT
> >  #define L1_CACHE_SHIFT               6
> > +#else
> > +#define L1_CACHE_SHIFT               5
> > +#endif
> >
> >  #define L1_CACHE_BYTES               (1 << L1_CACHE_SHIFT)
>
> Should we not instead just
>
> #define SMP_CACHE_BYTES L1_CACHE_BYTES
>
> like a handful of architectures do?
>

The generic code already defines it that way in include/linux/cache.h

> The cache size is sort of fake here, as we don't have any non-coherent
> mechanisms, but IIRC we wrote somewhere that it's recommended to have 64-byte
> cache lines in RISC-V implementations as software may assume that for
> performance reasons.  Not really a strong reason, but I'd prefer to just make
> these match.
>

If it is documented somewhere in the kernel, we should update that. I
think SMP_CACHE_BYTES being 64
actually degrades the performance as there will be a fragmented memory
blocks with 32 bit bytes gap wherever
SMP_CACHE_BYTES is used as an alignment requirement.

In addition to that, Geert Uytterhoeven mentioned some panic on vex32
without this patch.
I didn't see anything in Qemu though.


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



-- 
Regards,
Atish

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

  reply	other threads:[~2021-01-14 18:33 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07  9:26 [PATCH 0/4] Assorted fixes for RV32 Atish Patra
2021-01-07  9:26 ` Atish Patra
2021-01-07  9:26 ` [PATCH 1/4] RISC-V: Do not allocate memblock while iterating reserved memblocks Atish Patra
2021-01-07  9:26   ` Atish Patra
2021-01-08 16:25   ` Geert Uytterhoeven
2021-01-08 16:25     ` Geert Uytterhoeven
2021-01-11  3:54   ` Anup Patel
2021-01-11  3:54     ` Anup Patel
2021-01-07  9:26 ` [PATCH 2/4] RISC-V: Set current memblock limit Atish Patra
2021-01-07  9:26   ` Atish Patra
2021-01-11  3:58   ` Anup Patel
2021-01-11  3:58     ` Anup Patel
2021-01-11 19:20     ` Atish Patra
2021-01-11 19:20       ` Atish Patra
2021-01-07  9:26 ` [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32 Atish Patra
2021-01-07  9:26   ` Atish Patra
2021-01-08 16:26   ` Geert Uytterhoeven
2021-01-08 16:26     ` Geert Uytterhoeven
2021-01-11  4:00   ` Anup Patel
2021-01-11  4:00     ` Anup Patel
2021-01-14  5:09   ` Palmer Dabbelt
2021-01-14  5:09     ` Palmer Dabbelt
2021-01-14 18:33     ` Atish Patra [this message]
2021-01-14 18:33       ` Atish Patra
2021-01-14 19:46       ` Palmer Dabbelt
2021-01-14 19:46         ` Palmer Dabbelt
2021-01-14 21:11         ` Atish Patra
2021-01-14 21:11           ` Atish Patra
2021-01-14 21:24           ` Palmer Dabbelt
2021-01-14 21:24             ` Palmer Dabbelt
2021-01-15  7:59           ` Geert Uytterhoeven
2021-01-15  7:59             ` Geert Uytterhoeven
2021-01-15 22:44             ` Palmer Dabbelt
2021-01-15 22:44               ` Palmer Dabbelt
2021-01-17 19:03               ` Geert Uytterhoeven
2021-01-17 19:03                 ` Geert Uytterhoeven
2021-01-20 10:59                 ` Geert Uytterhoeven
2021-01-20 10:59                   ` Geert Uytterhoeven
2021-01-16  1:39             ` Atish Patra
2021-01-16  1:39               ` Atish Patra
2021-01-17 18:55               ` Geert Uytterhoeven
2021-01-17 18:55                 ` Geert Uytterhoeven
2021-03-12 15:52       ` Geert Uytterhoeven
2021-03-12 15:52         ` Geert Uytterhoeven
2021-01-07  9:26 ` [PATCH 4/4] RISC-V: Fix maximum allowed phsyical memory " Atish Patra
2021-01-07  9:26   ` Atish Patra
2021-01-11  4:04   ` Anup Patel
2021-01-11  4:04     ` Anup Patel
2021-01-11  4:05 ` [PATCH 0/4] Assorted fixes " Anup Patel
2021-01-11  4:05   ` Anup Patel
2021-01-14  5:09 ` Palmer Dabbelt
2021-01-14  5:09   ` Palmer Dabbelt
2021-01-14  5:12   ` Palmer Dabbelt
2021-01-14  5:12     ` 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='CAOnJCU+mCPwbeOQpmHmu3ar_17otmgftiKHLL+Z4_nExpj0=cA@mail.gmail.com' \
    --to=atishp@atishpatra.org \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=akpm@linux-foundation.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mick@ics.forth.gr \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.