Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into userspace child

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 28, 2013 at 09:45:02AM -0500, Tejun Heo wrote:
> Hello,
> 
> On Thu, Nov 28, 2013 at 03:38:57PM +0100, Peter Zijlstra wrote:
> > It seems like a perfectly fine interface to me. And much preferable to
> > creating yet another weird interface to manage tasks.
> 
> The problem with that is it isn't an interface where the user
> specifies what's desired but more of just an exposed facet of
> implementation details and locks us into either keeping that single
> parent model for the eternity or doing a shitty hack like extracing
> attributes from that task if we ever need to change the implementation
> for whatever reason.  In general, it's a much better idea to have an
> interface where the feature supported is represented explicitly and
> finitely.  If this is something which is actually necessary, I'd vote
> for having an explicit interface for the desired feature, whatever
> that may be.

The desired feature is to contain all current and future userspace
helpers.

Having the single parent allows using either cgroups or direct affinity
constraints, depending on whatever the user likes.

Related is the desire to contain all current and future unbound
workqueue threads. Not being able to set affinity (or cpusets for that
matter) on unbound workqueue threads actively breaks these things.

While the current use-cases I'm aware of treat these two groups as one,
I'm not sure we want to merge them.

The problem with yet another interface is that we'll likely expose just
the affinity, which would preclude using cgroups for this task.

Having single parents (even virtual as you propose, where we harvest
context attributes) allows us to easily find the extant child tasks and
set the desired attributes for future children with the full set of task
interfaces we've currently got.