All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Atish Patra <Atish.Patra@wdc.com>
Cc: linux-kernel@vger.kernel.org, Atish Patra <Atish.Patra@wdc.com>,
	aou@eecs.berkeley.edu, akpm@linux-foundation.org,
	Anup Patel <Anup.Patel@wdc.com>,
	ardb@kernel.org, linux-riscv@lists.infradead.org,
	rppt@kernel.org, Paul Walmsley <paul.walmsley@sifive.com>,
	mick@ics.forth.gr
Subject: Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32
Date: Wed, 13 Jan 2021 21:09:34 -0800 (PST)	[thread overview]
Message-ID: <mhng-1400a3dd-651b-4a78-bb2d-1f10580add75@palmerdabbelt-glaptop> (raw)
In-Reply-To: <20210107092652.3438696-4-atish.patra@wdc.com>

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 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.

WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Atish Patra <Atish.Patra@wdc.com>
Cc: aou@eecs.berkeley.edu, Anup Patel <Anup.Patel@wdc.com>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	Atish Patra <Atish.Patra@wdc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	mick@ics.forth.gr, akpm@linux-foundation.org, ardb@kernel.org,
	rppt@kernel.org
Subject: Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32
Date: Wed, 13 Jan 2021 21:09:34 -0800 (PST)	[thread overview]
Message-ID: <mhng-1400a3dd-651b-4a78-bb2d-1f10580add75@palmerdabbelt-glaptop> (raw)
In-Reply-To: <20210107092652.3438696-4-atish.patra@wdc.com>

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 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.

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

  parent reply	other threads:[~2021-01-14  5:10 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 [this message]
2021-01-14  5:09     ` Palmer Dabbelt
2021-01-14 18:33     ` Atish Patra
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=mhng-1400a3dd-651b-4a78-bb2d-1f10580add75@palmerdabbelt-glaptop \
    --to=palmer@dabbelt.com \
    --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=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.