Messages in this thread | | | Date | Fri, 8 Nov 2013 20:12:46 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd V2 |
| |
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.
| |