Messages in this thread | | | Date | Wed, 23 Dec 2009 14:52:40 +0800 | From | Herbert Xu <> | Subject | Re: workqueue thing |
| |
On Wed, Dec 23, 2009 at 12:37:32PM +0900, Tejun Heo wrote: > > I wrote this before but if something is burning CPU cycles using MT > workqueues, this can be easily supported by marking such workqueue as > not concurrency-managed. ie. Works queued for such workqueues > wouldn't contribute to the perceived workqueue concurrency and will be > left to be managed solely by the scheduler. This will completely > cover the crypto_wq case which uses MT workqueue with local cpu > binding.
Right, the main use of workqueues in the crypto subsystem currently is to perform operations in a process context, e.g., in order to use SSE instructions on x86, so there is no real parallelism involved.
However, Steffen Klassert has proposed a parallelisation mechanism whereby extremely CPU-intensive operations such as encryption may be split across CPUs. Steffen, could you repost your padata patches here?
Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
| |