Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions

[John Stultz]

On Thu, Jun 4, 2015 at 11:36 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> On Thu, Jun 04, 2015 at 10:11:17AM -0700, John Stultz wrote:
>> On Tue, Jun 2, 2015 at 10:50 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
>> > memcg usage came up a while ago and there wasn't anything major which
>> > can't be achieved (usually better) by following more standard cgroup
>> > usage - changing knobs rather than moving tasks around.
>>
>> Do you have a pointer to that discussion or maybe even just a sense of
>> who was involved so I can trawl the list and better understand it?
>
> I wrote a lengthy explanation of why moving tasks between cgroups is
> problematic from a memcg view: https://lkml.org/lkml/2014/12/19/358
>
> Rather than creating super-cgroups as configuration domains and using
> migration as a reconfiguration mechanism, it's much better to group
> tasks per app and reconfigure the groups themselves using specific
> presets for classes of apps, like foreground, background, audio.

Hmm. So I've not heard from the Android guys on the viability of this,
but one downside to this approach seems like that for cpu-scheduling
at least, using a per-task allocation would make it harder to bound
"background" cpu processing as a whole, no?

For example, In order to keep all background tasks to less then 20% of
the cputime, you'd have to set each process to get .2/nr_tasks (which
you'd have to recalculate & re-assign every time a new task is
launched). But that would end up being wasteful since each task gets
limited by that amount and cannot make use of cputime not used by
other background tasks.

Or am I misunderstanding the suggestion? Or is your concern just
limited to the memcg and this sort of cgroup migration ok for
scheduling?

And I guess, if its ok for scheduling, is it reasonable to consider
the proposed patch to allow "privileged" but non-root tasks to migrate
processes between cgroups?

thanks
-john
--
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/