On Fri, Nov 08, 2013 at 03:06:59PM +0000, Christoph Lameter wrote: > On Thu, 7 Nov 2013, Frederic Weisbecker wrote: > > > usermodehelper works are created via workqueues, right? And workqueues are > > an issue as > > well for those who want CPU isolation. > > AFAICT usermodehelper can be called from a variety of contexts.
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. BTW the use of kernel_thread is justified in this comment: "/* Keventd can't block, but this (a child) can. */" Do these kernel_threads exist because kworker can't block? Actually the new workqueue subsystem can have blocking worklets now, may be something can be simplified there although I haven't checked the details. But perhaps we can spare one level of kernel threads. Can't we use kthreads there btw? Or may be we need a task->mm to do the user things. > > > So this looks like a more general problem than just call_usermodehelper. > > Well the code explicitly sets the the affinity mask to all cpus which > creates a problem for low latency processors. It does not inherit the > affinity from any calling process. But how is that an argument in favour of changing this to inheriting the affinity from the workqueue thread rather than kthread? > > > Last time I checked, it seemed to me that this is an unbound workqueue? If > > so can't we tune > > the affinity of this workqueue? If not perhaps that's something we want to > > solve and which > > could be useful for all the users who don't want their CPU to be disturbed. > > There are various contexts from which usermodehelper can be called. > Drivers use it etc. But they all converge to the workqueue, or I'm missing other code paths? Thanks. -- 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/
