Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH v2 04/19] crypto: x86/sha - limit FPU preemption | Date | Fri, 14 Oct 2022 11:01:12 +0000 |
| |
From: Jason A. Donenfeld > Sent: 13 October 2022 01:42 ... > > diff --git a/arch/x86/crypto/sha1_ssse3_glue.c b/arch/x86/crypto/sha1_ssse3_glue.c > > index 44340a1139e0..a9f5779b41ca 100644 > > --- a/arch/x86/crypto/sha1_ssse3_glue.c > > +++ b/arch/x86/crypto/sha1_ssse3_glue.c > > @@ -26,6 +26,8 @@ > > #include <crypto/sha1_base.h> > > #include <asm/simd.h> > > > > +#define FPU_BYTES 4096U /* avoid kernel_fpu_begin/end scheduler/rcu stalls */ > > Declare this inside the function it's used as an untyped enum, and give > it a better name, like BYTES_PER_FPU.
Isn't 'bytes' the wrong unit anyway? At least it ought to be 'clocks' so it can be divided by the (approximate) 'clocks per byte' of the algorithm.
Something like a crc is likely to be far faster than AES.
Clearly the actual required units are microseconds. But depending on the actual cpu frequency is a bit hard. And people running faster cpu may want lower latency anyway. So a typical slow cpu frequency is probably ok.
The actual architecture dependant constant really ought to be defined with kernel_fpu_begin().
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |