Messages in this thread |  | | Date | Thu, 28 Nov 2013 15:53:52 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into userspace child |
| |
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.
|  |