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 cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
