lkml.org 
[lkml]   [2022]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v2 04/19] crypto: x86/sha - limit FPU preemption
Date
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)
\
 
 \ /
  Last update: 2022-10-14 13:02    [W:0.150 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site