[dm-devel] [RFC PATCH 00/20] dm-crypt: parallel processing

[Tejun Heo]

Hello,

On Wed, Aug 22, 2012 at 12:28:41PM +0200, Milan Broz wrote:
> Whatever, if logic is implemented in workqueue code, others can use t as well.
> I would really prefer not to have "too smart" dmcrypt...
> (Someone mentioned btrfs on top of it with all workqueues - how it can behave nicely
> if every layer will try to implement own smart logic.)
> 
> Anyway, thanks for discussion, this is exactly what was missing here :)

I've been thinking about it and am still unsure.  If there are enough
use cases, we can try to manage unbound workers such that each CPU has
some standby ones, but at this point such approach seems a bit
overkill and I'm skeptical how useful a purely opportunistic approach
would be.

Another thing is that this is something which really belongs to the
scheduler.  The scheduler can know better and do things like this much
better.  Unfortunately, kthreads don't have mechanisms to be
discovered in terms of its optimal association (as opposed to, say,
autonuma for userland).

So... I don't know.  dm-crypt probably is the most extreme use case in
kernel, so maybe going for specialized solution might not be too
crazy.  Also, how much of a problem is this?  Is it really worth
solving?

Thanks.

-- 
tejun