keventd_wq has potential starvation problem, so use dedicated
kcrypto_wq instead.
Signed-off-by: Huang Ying
---
crypto/Kconfig |1 +
crypto/chainiv.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -56,6 +56,7 @@ config CRYPTO_BLKC
Original cryptd thread implementation has scalability issue, this
patch solve the issue with a per-CPU thread implementation.
struct cryptd_queue is defined to be a per-CPU queue, which holds one
struct cryptd_cpu_queue for each CPU. In struct cryptd_cpu_queue, a
struct crypto_queue holds all requ
A dedicated workqueue named kcrypto_wq is created to be used by crypto
subsystem. The system shared keventd_wq is not suitable for
encryption/decryption, because of potential starvation problem.
Signed-off-by: Huang Ying
---
crypto/Kconfig |3 +++
crypto/Makefile|
On Mon, Feb 02, 2009 at 11:30:25AM +0800, Huang Ying wrote:
>
> The only needed spin lock usage is cryptd_tfm_in_queue() now, I think we
> can protect that via RCU, what's your opinions?
We should just get rid of cryptd_tfm_in_queue since it's only used
for debugging.
> But I think the simplest
On Thu, 2009-01-22 at 15:30 +0800, Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 03:15:58PM +0800, Huang Ying wrote:
The only needed spin lock usage is cryptd_tfm_in_queue() now, I think we
can protect that via RCU, what's your opinions?
> > Yes. Except that, now we do not need a spin lock really.
I design a performance testing for cryptd with a little modified
dm-crypt. The testing script is as follow:
script begin ---
#!/bin/sh
dmc_create()
{
# Create a crypt device using dmsetup
dmsetup create $2 --table "0 `blockdev --getsize
Sorry for my late. Last week is Chinese new year holiday.
On Sat, 2009-01-24 at 15:07 +0800, Andrew Morton wrote:
> On Thu, 22 Jan 2009 10:32:17 +0800 Huang Ying wrote:
>
> > Use dedicate workqueue for crypto
> >
> > - A dedicated workqueue named kcrypto_wq is created.
> >
> > - chainiv uses k
