Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1608167

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

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

Show all headers | View raw


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 | NextPrevious in thread | Find similar | Unroll thread


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