[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4B/kjS0lgzdUJHG@gondor.apana.org.au>
Date: Fri, 25 Nov 2022 16:40:50 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Robert Elliott <elliott@....com>, davem@...emloft.net,
tim.c.chen@...ux.intel.com, ap420073@...il.com, ardb@...nel.org,
David.Laight@...lab.com, ebiggers@...nel.org,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [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@...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