[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7FblsbOQnJ7sYOA@gondor.apana.org.au>
Date: Sun, 16 Feb 2025 11:29:26 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Jakub Kicinski <kuba@...nel.org>, fsverity@...ts.linux.dev,
linux-crypto@...r.kernel.org, dm-devel@...ts.linux.dev,
x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Alasdair Kergon <agk@...hat.com>, Mike Snitzer <snitzer@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mikulas Patocka <mpatocka@...hat.com>,
David Howells <dhowells@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v8 0/7] Optimize dm-verity and fsverity using multibuffer
hashing
On Sat, Feb 15, 2025 at 07:26:16PM -0800, Eric Biggers wrote:
>
> Well, the async fallback (using cryptd) occurs only when a kernel-mode FPU
> section in process context is interrupted by a hardirq and at the end of it a
> softirq also tries to use kernel-mode FPU. It's generally a rare case but also
> a terrible implementation that is really bad for performance; this should never
It may not be rare if the kernel is busy doing bidirectional
TX/RX with crypto. The process context will be the TX-side
encrypting while the softirq context will do RX-side decryption.
> have been implemented this way. I am planning to fix it so that softirqs on x86
Sure but it's way better than falling back to the C implementation
on the RX-side.
> will always be able to use the FPU, like they can on some of the other arches
> like arm64 and riscv.
That's great news. Thanks!
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists