All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nam Cao <namcao@linutronix.de>
To: Michael Neuling <mikey@neuling.org>,
	patchwork-bot+linux-riscv@kernel.org
Cc: linux-riscv@lists.infradead.org, pjw@kernel.org,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	ajones@ventanamicro.com, cleger@rivosinc.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] riscv: Cleanup and deduplicate unaligned access speed probe
Date: Tue, 07 Apr 2026 09:35:19 +0200	[thread overview]
Message-ID: <87wlyj4408.fsf@yellow.woof> (raw)
In-Reply-To: <CAEjGV6y0=bSLp_wrS0uHFj1S2TCRtz4GKzaU5O-L1VV-EL7Nnw@mail.gmail.com>

Michael Neuling <mikey@neuling.org> writes:
>> This series was applied to riscv/linux.git (for-next)
>> by Paul Walmsley <pjw@kernel.org>:
>
>> Here is the summary with links:
>>   - [1/5] riscv: Clean up & optimize unaligned scalar access probe
>>     https://git.kernel.org/riscv/c/c202d70b2244
>
> I think this is causing a regression (SHA1 actually 6455c6c11827) .
> Fast unaligned accesses are no longer being set ever.
>
> Analysis from Claude (Opus 4.6) with Chris Masons kernel patch review skills:

I should start using these AIs..

> --
>   > diff --git a/arch/riscv/kernel/unaligned_access_speed.c
> b/arch/riscv/kernel/unaligned_access_speed.c
>   > index b36a6a56f4..1f4c128d73 100644
>   > --- a/arch/riscv/kernel/unaligned_access_speed.c
>   > +++ b/arch/riscv/kernel/unaligned_access_speed.c
>
>   [ ... ]
>
>   > -arch_initcall(check_unaligned_access_all_cpus);
>   > +late_initcall(check_unaligned_access_all_cpus);
>
>   With this change, check_unaligned_access_all_cpus() now runs at
>   late_initcall (level 7), but lock_and_set_unaligned_access_static_branch()
>   remains at arch_initcall_sync (level 3s):
...
>   Does this mean fast_unaligned_access_speed_key is never enabled at boot,
>   even on hardware with fast unaligned access? The comment in
>   set_unaligned_access_static_branches() says "This will be called after
>   check_unaligned_access_all_cpus" which is no longer true with this
>   ordering change.

Thanks, you are indeed right. This affects do_csum()'s performance.

The below patch should resolve the issue. I will send a proper patch
later today after I have tested with my hardware.

Nam

diff --git a/arch/riscv/kernel/unaligned_access_speed.c b/arch/riscv/kernel/unaligned_access_speed.c
index 485ab1d105d3..96ba80e6ea32 100644
--- a/arch/riscv/kernel/unaligned_access_speed.c
+++ b/arch/riscv/kernel/unaligned_access_speed.c
@@ -244,7 +244,7 @@ static int __init lock_and_set_unaligned_access_static_branch(void)
 	return 0;
 }
 
-arch_initcall_sync(lock_and_set_unaligned_access_static_branch);
+late_initcall_sync(lock_and_set_unaligned_access_static_branch);
 
 static int riscv_online_cpu(unsigned int cpu)
 {

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

      reply	other threads:[~2026-04-07  7:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11 17:30 [PATCH 0/5] riscv: Cleanup and deduplicate unaligned access speed probe Nam Cao
2026-02-11 17:30 ` [PATCH 1/5] riscv: Clean up & optimize unaligned scalar access probe Nam Cao
2026-02-11 17:30 ` [PATCH 2/5] riscv: Split out measure_cycles() for reuse Nam Cao
2026-02-11 17:30 ` [PATCH 3/5] riscv: Reuse measure_cycles() in check_vector_unaligned_access() Nam Cao
2026-02-11 17:30 ` [PATCH 4/5] riscv: Split out compare_unaligned_access() Nam Cao
2026-02-11 17:30 ` [PATCH 5/5] riscv: Reuse compare_unaligned_access() in check_vector_unaligned_access() Nam Cao
2026-04-03 18:30 ` [PATCH 0/5] riscv: Cleanup and deduplicate unaligned access speed probe patchwork-bot+linux-riscv
2026-04-07  1:38   ` Michael Neuling
2026-04-07  7:35     ` Nam Cao [this message]

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=87wlyj4408.fsf@yellow.woof \
    --to=namcao@linutronix.de \
    --cc=ajones@ventanamicro.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=cleger@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mikey@neuling.org \
    --cc=palmer@dabbelt.com \
    --cc=patchwork-bot+linux-riscv@kernel.org \
    --cc=pjw@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.