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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
