On Mon, Jul 27, 2015 at 02:48:40PM -0400, Tejun Heo wrote: > On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote: > > Hence those two debatable changes: > > > > _ We would like to use generic workqueues. System unbound workqueues are > > a very good candidate but they are not wide affine, only node affine. > > Now probably a node is enough to perform many parallel kmod jobs. > > If being node-affine is an issue, kmod can easily create a workqueue > w/o NUMA affinity using apply_workqueue_attrs() with no_numa set to > %true.
Right, but we would like to get rid of khelper which already plays a similar role. > > > _ We would like to remove the wait_for_helper kernel thread (UMH_WAIT_PROC > > handler) to use the workqueue. It means that if the workqueue blocks, > > and no other worker can take pending kmod request, we can be screwed. > > Now if we have 512 threads, this should be enough. > > The maximum number of worker can also be raised on the workqueue. > That said, I don't think we want to. > > IMHO, system_wq should be fine and if it isn't turning off numa > affinity or raising max worker limit later is pretty trivial. That's what I think too. How many workers system_unbound_wq can handle? If kmod raises very high numbers of threads in parallel like > 500, I think that would be a problem on its own anyway. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
