Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1608167
| From | "Joel Fernandes (Google)" <joel.opensrc@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller |
| Date | 2017-03-24 08:10 +0100 |
| Message-ID | <torwd-6nm-1@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <tfRpT-5QG-1@gated-at.bofh.it> <tn9rI-81U-17@gated-at.bofh.it> <tn9UL-8sD-71@gated-at.bofh.it> <tnYNz-2xC-5@gated-at.bofh.it> <to8jU-XG-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Patrick, On Thu, Mar 23, 2017 at 3:32 AM, Patrick Bellasi <patrick.bellasi@arm.com> 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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-20 19:10 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-03-23 01:30 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-23 11:40 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Tejun Heo <tj@kernel.org> - 2017-03-23 17:10 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-23 19:20 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Tejun Heo <tj@kernel.org> - 2017-03-23 19:40 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-03-24 07:40 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller Tejun Heo <tj@kernel.org> - 2017-03-24 16:10 +0100
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-03-24 08:10 +0100
csiph-web