Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755948AbdCXHCj (ORCPT ); Fri, 24 Mar 2017 03:02:39 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35097 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755476AbdCXHCe (ORCPT ); Fri, 24 Mar 2017 03:02:34 -0400 MIME-Version: 1.0 In-Reply-To: <20170323103254.GA11362@e110439-lin> References: <1488292722-19410-1-git-send-email-patrick.bellasi@arm.com> <1488292722-19410-2-git-send-email-patrick.bellasi@arm.com> <20170320171511.GB3623@htj.duckdns.org> <20170320180837.GB28391@e110439-lin> <20170323103254.GA11362@e110439-lin> From: "Joel Fernandes (Google)" Date: Fri, 24 Mar 2017 00:02:15 -0700 Message-ID: Subject: Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller To: Patrick Bellasi Cc: Tejun Heo , Linux Kernel Mailing List , linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra 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: 2057 Lines: 53 Hi Patrick, On Thu, Mar 23, 2017 at 3:32 AM, Patrick Bellasi wrote: [..] >> > which can be used to defined tunable root constraints when CGroups are >> > not available, and becomes RO when CGroups are. >> > >> > Can this be eventually an acceptable option? >> > >> > In any case I think that this feature will be mainly targeting CGroup >> > based systems. Indeed, one of the main goals is to collect >> > "application specific" information from "informed run-times". Being >> > "application specific" means that we need a way to classify >> > applications depending on the runtime context... and that capability >> > in Linux is ultimately provided via the CGroup interface. >> >> I think the concern raised is more about whether CGroups is the right >> interface to use for attaching capacity constraints to task or groups >> of tasks, or is there a better way to attach such constraints? > > Notice that CGroups based classification allows to easily enforce > the concept of "delegation containment". I think this feature should > be nice to have whatever interface we choose. > > However, potentially we can define a proper per-task API; are you > thinking to something specifically? > I was thinking how about adding per-task constraints to the resource limits API if it makes sense to? There's already RLIMIT_CPU and RLIMIT_NICE. An informed-runtime could then modify the limits of tasks using prlimit. >> The other advantage of such interface is we don't have to >> create a separate CGroup for every new constraint limit and can have >> several tasks with different unique constraints. > > That's still possible using CGroups and IMO it will not be the "most > common case". > Don't you think that in general we will need to set constraints at > applications level, thus group of tasks? Some applications could be a single task, also not all tasks in an application may need constraints right? > As a general rule we should probably go for an interface which makes > easy the most common case. I agree. Thanks, Joel