Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY intouserspace child

[Tejun Heo]

On Thu, Nov 28, 2013 at 03:59:48PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 28, 2013 at 09:57:23AM -0500, Tejun Heo wrote:
> > On Thu, Nov 28, 2013 at 03:55:05PM +0100, Peter Zijlstra wrote:
> > > Because that is exactly what some users desire? Some RT and HPC people
> > > want all those crypt jobs to run on a few designated cpus and not wreck
> > > their compute jobs.
> > 
> > And you can't do that reliably from userland.  Those things are
> > created dynamically.  workqueue provides per-workqueue attributes to
> > enable those use cases.  It doesn't have system-wide default
> > attributes right now but adding that shouldn't be too difficult.
> 
> Like a parent process, right? So people can use the existing task
> interfaces.
>
> Or are we going to tell people; here, there's cgroups for managing your
> tasks. Oh and here is this crippled interface X for if you want to
> manage these few tasks, and interface Y for managing these other few
> tasks.

Changing attributes on the parent doesn't get propagated to its
children, so I don't think that'd be a terribly good interface for
workqueue.  You'll end up with workers with mixed attributes and
regardless, workqueue management logic needs to know which workqueue
has which set of attributes to decide how the workers are shared.
Overrloading all that over task mgmt interface would be horrible.

For transient processes like usermode helpers, single parent could
work.  I don't necessarily think exposing that is a good idea but if
that's gonna happen, that's not gonna be part of workqueue.  Just
create a dedicated kthread for it.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/