Re: [PATCH 2/5] kmod: Use system_unbound_wq instead of khelper

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Jul 10, 2015 at 02:05:56PM -0500, Christoph Lameter wrote:
> On Fri, 10 Jul 2015, Frederic Weisbecker wrote:
> 
> > Note that nohz full is perfectly fine with that. The issue I'm worried about
> > is the case where drivers spawn hundreds of jobs and it all happen on the same
> > node because the kernel threads inherit the workqueue affinity, instead of
> > the global affinity that khelper had.
> 
> Well if this is working as intended here then the kernel threads will only
> run on a specific cpu. As far as we can tell the amout of kernel threads
> spawned is rather low

Quite high actually. I count 578 calls on my machine. Most of them are launched
by crypto subsystem trying to load modules. And it takes more than one second to
complete all of these requests...

> and also the performance requirements on those
> threads are low.

I think it is sensitive given the possible high number of instances launched. Now
at least the crypto subsystem hasn't optimized that at all because all these
instances are serialized. Basically on my machine, all of them run on CPU 0.

Now I'm worried about other configs that may launch loads of parallel
usermodehelper threads. That said I tend to think that if such a thing hasn't
been seen as a problem on small SMP systems, why would it be an issue if we
affine them on a NUMA node that is usually at least 4 CPUs wide? Or is it possible
to see lower numbers of CPUs in a NUMA node?