> -----Original Message----- > From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Sent: Friday, August 19, 2022 6:05 AM > Subject: Re: [PATCH] crypto: x86/sha512 - load based on CPU features > > Robert Elliott <elliott@xxxxxxx> wrote: > > x86 optimized crypto modules built as modules rather than built-in > > to the kernel end up as .ko files in the filesystem, e.g., in > > /usr/lib/modules. If the filesystem itself is a module, these might > > not be available when the crypto API is initialized, resulting in > > the generic implementation being used (e.g., sha512_transform rather > > than sha512_transform_avx2). > > > > In one test case, CPU utilization in the sha512 function dropped > > from 15.34% to 7.18% after forcing loading of the optimized module. > > > > Add module aliases for this x86 optimized crypto module based on CPU > > feature bits so udev gets a chance to load them later in the boot > > process when the filesystems are all running. > > > > Signed-off-by: Robert Elliott <elliott@xxxxxxx> > > --- > > arch/x86/crypto/sha512_ssse3_glue.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > Patch applied. Thanks. I'll post a series that applies this technique to all the other x86 modules, if there are no problems reported with sha512. Do other architectures have the same issue, or is something else done to ensure that modules are loaded? MODULE_DEVICE_TABLE() is used by three other architecture-specific modules: 1. One arm (32-bit) module, matching on certain Arm extensions: arch/arm/crypto/crc32-ce-glue.c:MODULE_DEVICE_TABLE(cpu, crc32_cpu_feature); 2. One arm64 module, matching on certain Arm extensions: arch/arm64/crypto/ghash-ce-glue.c:MODULE_DEVICE_TABLE(cpu, ghash_cpu_feature); 3. All of the sparc modules share a global solution: arch/sparc/crypto/crop_devid.c:MODULE_DEVICE_TABLE(of, crypto_opcode_match); /* This is a dummy device table linked into all of the crypto * opcode drivers. It serves to trigger the module autoloading * mechanisms in userspace which scan the OF device tree and * load any modules which have device table entries that * match OF device nodes. */ Each module .c file includes that .c file: aes_glue.c:#include "crop_devid.c" camellia_glue.c:#include "crop_devid.c" crc32c_glue.c:#include "crop_devid.c" des_glue.c:#include "crop_devid.c" md5_glue.c:#include "crop_devid.c" sha1_glue.c:#include "crop_devid.c" sha256_glue.c:#include "crop_devid.c" sha512_glue.c:#include "crop_devid.c"
