All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>, u-boot@lists.denx.de
Cc: sjg@chromium.org, trini@konsulko.com
Subject: Re: [PATCH v1 2/5] board_init: Use memset_simple() in board_init_f_init_reserve()
Date: Mon, 9 Aug 2021 15:17:06 +0200	[thread overview]
Message-ID: <e3a6c25d-c0e1-0700-c730-0e9fccd037a8@denx.de> (raw)
In-Reply-To: <bb2b4621-a935-a9be-c421-7090050d44e0@prevas.dk>

Hi Rasmus,

On 09.08.21 09:52, Rasmus Villemoes wrote:
> On 06/08/2021 15.38, Stefan Roese wrote:
>> board_init_f_init_reserve() is called very early in the boot process,
>> before the caches are enabled. Because of this, the optimized memset()
>> version can't be used here on ARM64. With this patch, the simple memset
>> version memset_simple() is used here instead.
> 
> I'm afraid this approach is pretty much whack-a-mole, and it's also a
> pity that one arch's limitations/special needs affects common code.

I fully agree - I was (am) also not really happy with the suggested
implemented.

> It
> also means we lose the compiler's knowledge of "ah, here you're calling
> a standard library function whose semantics I know".
> 
> The linux kernel has a lot of instances of self-modifying code
> (alternatives, static keys, etc.). Could we do something like that in
> U-Boot? That is, have the optimized asm version of memset start with an
> unconditional jump to memset_simple, then when the arch is ready,
> overwrite that jump instruction with a nop. Compared to the kernel, we
> don't have any complications from multiple CPUs, so it shouldn't be too
> hard.
> 
> That would allow all callers to just call memset(), which is better both
> for the compiler and the human brain. Also, when somebody modifies the
> common code later, they won't know that they need to spell memset
> "memset_simple", as their modifications probably work just fine on their
> platforms, but then it'll explode on ARM64. And finally, what happens if
> somebody disables caches at run-time?

U-Boot crashes! I forgot about this problem.

> Shouldn't we then also have a
> mechanism to switch all mem* calls over to the simple versions?

AFAICT, it's only the "dc" opcode which needs caching enabled. And "dc"
is only used in memset() and not memcpy().

Let me think again about either using your suggestion with the self
modifying code or perhaps by adding a "cache enable" check in the
new memset() function.

Thanks for your valuable feedback.

Thanks,
Stefan

  reply	other threads:[~2021-08-09 13:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 13:38 [PATCH v1 0/5] arm64: Add optimized memset/memcpy functions Stefan Roese
2021-08-06 13:38 ` [PATCH v1 1/5] lib/string: Add memset_simple() Stefan Roese
2021-08-06 15:36   ` Wolfgang Denk
2021-08-06 16:13     ` Heinrich Schuchardt
2021-08-07 15:18       ` Wolfgang Denk
2021-08-07 15:34         ` Tom Rini
2021-08-06 13:38 ` [PATCH v1 2/5] board_init: Use memset_simple() in board_init_f_init_reserve() Stefan Roese
2021-08-09  7:52   ` Rasmus Villemoes
2021-08-09 13:17     ` Stefan Roese [this message]
2021-08-06 13:38 ` [PATCH v1 3/5] arm64: cache_v8: Use memset_simple() in create_table() Stefan Roese
2021-08-06 13:38 ` [PATCH v1 4/5] arm64: arch/arm/lib: Add optimized memset/memcpy functions Stefan Roese
2021-08-06 14:43   ` Tom Rini
2021-08-06 14:45     ` Stefan Roese
2021-08-06 15:41   ` Wolfgang Denk
2021-08-06 13:38 ` [PATCH v1 5/5] arm64: Kconfig: Enable usage of optimized memset/memcpy Stefan Roese
2021-08-06 14:24 ` [PATCH v1 0/5] arm64: Add optimized memset/memcpy functions Tom Rini
2021-08-06 14:44   ` Stefan Roese

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=e3a6c25d-c0e1-0700-c730-0e9fccd037a8@denx.de \
    --to=sr@denx.de \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.