On Tue, Jul 08, 2025 at 03:33:34PM +0800, Yuwen Chen wrote: > On Thu, 3 Jul 2025 22:14:41 -0700, Eric Biggers wrote: > > I'm guessing you have some debugging options enabled in your kconfig. > > Usually > > the allocations aren't quite *that* expensive. That being said, it's always > > been really annoying that they have to be there. > > Turn off most of the debugging options and merge these two patches > for memory allocation. The performance test results are as follows: > Before this submission was merged, when creating 10000 files, > the performance test results are as follows: > $ time /data/file_creater 10000 > 0m10.90s real 0m00.00s user 0m10.69s system > > After merge these two patches, the performance is as follows: > $ time /data/file_creater 10000 > 0m05.32s real 0m00.00s user 0m05.28s system > > > Unfortunately, as far as I know, you actually can't just allocate the > > skcipher_request on the stack like that, since the legacy crypto API assumes > > that the request memory is DMA-able. On-stack requests also might not be > > properly aligned (see > > https://lore.kernel.org/all/ca+55afxjozmim_d-o2e2yip8jwo0ndys_72snwfksktjy8q...@mail.gmail.com/ > > -- may be outdated, but I haven't heard otherwise). > > Thank you for the reminder. This should be a problem here. > Just, why can SYNC_SKCIPHER_REQUEST_ON_STACK be allocated on > the stack? Is it possible to use ALIGN to achieve alignment?
I suppose that in practice the request alignment only matters for the off-CPU offloads, and that's how SYNC_SKCIPHER_REQUEST_ON_STACK gets away with maybe not aligning the request reliably. If you look at e.g. the software AES-XTS code, it doesn't even use the request context at all, which makes the entire exercise a bit pointless. I'm thinking we should just go ahead and use sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK for now. Previously this was impossible because the x86 accelerated AES-XTS algorithms had CRYPTO_ALG_ASYNC set, but now it is possible. Can you review and test the following patchset: https://lore.kernel.org/linux-fscrypt/20250708181313.66961-1-ebigg...@kernel.org/ ? - Eric
