On Fri, Nov 08, 2013 at 05:05:35PM +0000, Christoph Lameter wrote: > 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 understand, but why not solving that from the workqueue affinity? We want to solve the issue of unbound workqueues in CPU isolation anyway. > > 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. I got that, and I too am interested in solving this problem. I'm not fighting against the purpose of this patch but against the way we solve that. -- 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/
