Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbbFEV27 (ORCPT ); Fri, 5 Jun 2015 17:28:59 -0400 Received: from mail-ie0-f176.google.com ([209.85.223.176]:35521 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751968AbbFEV2y (ORCPT ); Fri, 5 Jun 2015 17:28:54 -0400 MIME-Version: 1.0 In-Reply-To: <20150604183658.GA5682@cmpxchg.org> References: <1432179674-19154-1-git-send-email-john.stultz@linaro.org> <20150603055057.GE20091@mtj.duckdns.org> <20150604183658.GA5682@cmpxchg.org> Date: Fri, 5 Jun 2015 14:28:54 -0700 Message-ID: Subject: Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions From: John Stultz To: Johannes Weiner Cc: Tejun Heo , lkml , Li Zefan , Jonathan Corbet , cgroups@vger.kernel.org, Android Kernel Team , Rom Lemarchand , Colin Cross Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2172 Lines: 45 On Thu, Jun 4, 2015 at 11:36 AM, Johannes Weiner 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/