From: Eric Biggers <ebiggers@kernel.org>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
loongarch@lists.linux.dev, sparclinux@vger.kernel.org,
x86@kernel.org, Hendrik Brueckner <brueckner@linux.ibm.com>
Subject: Re: [PATCH 07/15] s390/crc32: expose CRC32 functions through lib
Date: Mon, 21 Oct 2024 17:56:40 +0000 [thread overview]
Message-ID: <20241021175640.GA1370449@google.com> (raw)
In-Reply-To: <20241021104007.6950-E-hca@linux.ibm.com>
On Mon, Oct 21, 2024 at 12:40:07PM +0200, Heiko Carstens wrote:
> What makes sure that all of the code is available automatically if the
> CPU supports the instructions like before? I can see that all CRC32
> related config options support also module build options.
>
> Before this patch, this module and hence the fast crc32 variants were
> loaded automatically when required CPU features were present.
> Right now I don't how this is happening with this series.
There's just a direct symbol dependency now. For example
ext4.ko -> crc32-s390.ko [crc32c_le_arch] -> crc32.ko [crc32c_le_base].
So, crc32-$arch.ko always gets loaded when there is a user of one of the CRC32
library functions, provided that it was enabled in the kconfig.
crc32-$arch then calls either the accelerated code or the base code depending on
the CPU features. On most architectures including s390, I made this use a
static branch, so there is almost no overhead (much less overhead than the
indirect call that was needed before).
This is the same way that some of the crypto library code already works.
> > +static int __init crc32_s390_init(void)
> > +{
> > + if (cpu_have_feature(S390_CPU_FEATURE_VXRS))
> > + static_branch_enable(&have_vxrs);
> > + return 0;
> > +}
> > +arch_initcall(crc32_s390_init);
>
> I guess this should be changed to:
>
> module_cpu_feature_match(S390_CPU_FEATURE_VXRS, ...);
>
> Which would make at least the library functions available if cpu
> features are present. But this looks only like a partial solution of
> the above described problem.
>
> But maybe I'm missing something.
This is not needed, as per the above.
- Eric
next prev parent reply other threads:[~2024-10-21 17:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 0:29 [PATCH 00/15] Wire up CRC32 library functions to arch-optimized code Eric Biggers
2024-10-21 0:29 ` [PATCH 01/15] lib/crc32: drop leading underscores from __crc32c_le_base Eric Biggers
2024-10-21 0:29 ` [PATCH 02/15] lib/crc32: improve support for arch-specific overrides Eric Biggers
2024-10-21 0:29 ` [PATCH 03/15] arm/crc32: expose CRC32 functions through lib Eric Biggers
2024-10-21 0:29 ` [PATCH 04/15] loongarch/crc32: " Eric Biggers
2024-10-21 0:29 ` [PATCH 05/15] mips/crc32: " Eric Biggers
2024-10-21 0:29 ` [PATCH 06/15] powerpc/crc32: " Eric Biggers
2024-10-21 0:29 ` [PATCH 07/15] s390/crc32: " Eric Biggers
2024-10-21 10:40 ` Heiko Carstens
2024-10-21 17:56 ` Eric Biggers [this message]
2024-10-21 0:29 ` [PATCH 08/15] sparc/crc32: " Eric Biggers
2024-10-21 0:29 ` [PATCH 09/15] x86/crc32: update prototype for crc_pcl() Eric Biggers
2024-10-21 0:29 ` [PATCH 10/15] x86/crc32: update prototype for crc32_pclmul_le_16() Eric Biggers
2024-10-21 0:29 ` [PATCH 11/15] x86/crc32: expose CRC32 functions through lib Eric Biggers
2024-10-21 0:29 ` [PATCH 12/15] lib/crc32: make crc32c() go directly to lib Eric Biggers
2024-10-21 0:29 ` [PATCH 13/15] ext4: switch to using the crc32c library Eric Biggers
2024-10-21 0:29 ` [PATCH 14/15] jbd2: " Eric Biggers
2024-10-21 0:29 ` [PATCH 15/15] f2fs: switch to using the crc32 library Eric Biggers
2024-10-25 7:40 ` [PATCH 00/15] Wire up CRC32 library functions to arch-optimized code Ard Biesheuvel
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=20241021175640.GA1370449@google.com \
--to=ebiggers@kernel.org \
--cc=brueckner@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=x86@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 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).