lkml.org 
[lkml]   [2022]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption
On Wed, Nov 16, 2022 at 12:13:51PM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 15, 2022 at 10:13:28PM -0600, Robert Elliott wrote:
> > +/* avoid kernel_fpu_begin/end scheduler/rcu stalls */
> > +static const unsigned int bytes_per_fpu = 337 * 1024;
> > +
>
> Use an enum for constants like this:
>
> enum { BYTES_PER_FPU = ... };
>
> You can even make it function-local, so it's near the code that uses it,
> which will better justify its existence.
>
> Also, where did you get this number? Seems kind of weird.

These numbers are highly dependent on hardware and I think having
them hard-coded is wrong.

Perhaps we should try a different approach. How about just limiting
the size to 4K, and then depending on need_resched we break out of
the loop? Something like:

if (!len)
return 0;

kernel_fpu_begin();
for (;;) {
unsigned int chunk = min(len, 4096);

sha1_base_do_update(desc, data, chunk, sha1_xform);

len -= chunk;
data += chunk;

if (!len)
break;

if (need_resched()) {
kernel_fpu_end();
cond_resched();
kernel_fpu_begin();
}
}
kernel_fpu_end();

Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

\
 
 \ /
  Last update: 2022-11-25 09:41    [W:1.622 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site