On Fri, 8 Nov 2013, Frederic Weisbecker wrote: > But it looks like it always end up calling a workqueue. May be I missed > something though. > > Now we can argue that this workqueue seem to create kernel threads, which in > turn create other kernel thread (uhh?) > and I don't know if those inherit the kworker affinity. But from a quick > look, it seems to me that > this is what we want.
Right. The problem is that the affinity cannot be inherited since usermodehelper may be called from a workqueue or other restricted kernel context. The main point of the usermodehelper logic is to work itself out of the restrictions of the context in which is was called to be able to fork off a kernel thread that then can call a userspace helper program. I want to restrict on which processors this working out of the limiting context can occur. It should not occur on low latency processors nor should user space stuff be run there. Without this patch we see various processes being sprinkled over all the processors in the system when usermodehelper is invoked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
