On Wed, Sep 12, 2018 at 5:51 AM, Patrick Bellasi
wrote:
> On 08-Sep 20:02, Suren Baghdasaryan wrote:
>> On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
>> wrote:
>
> [...]
>
>> > + cpu.util.min.effective
>> > +A read-only single value file which exists on non-root cgroups and
>> > +
On Wed, Sep 12, 2018 at 5:51 AM, Patrick Bellasi
wrote:
> On 08-Sep 20:02, Suren Baghdasaryan wrote:
>> On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
>> wrote:
>
> [...]
>
>> > + cpu.util.min.effective
>> > +A read-only single value file which exists on non-root cgroups and
>> > +
On 08-Sep 20:02, Suren Baghdasaryan wrote:
> On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
> wrote:
[...]
> > + cpu.util.min.effective
> > +A read-only single value file which exists on non-root cgroups and
> > +reports minimum utilization clamp value currently enforced on a
On 08-Sep 20:02, Suren Baghdasaryan wrote:
> On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
> wrote:
[...]
> > + cpu.util.min.effective
> > +A read-only single value file which exists on non-root cgroups and
> > +reports minimum utilization clamp value currently enforced on a
Hello, Patrick.
On Tue, Sep 11, 2018 at 05:26:24PM +0100, Patrick Bellasi wrote:
> My question is: IF the scheduler maintainers are going to be happy
> with the overall design for the core bits, are you happy to start the
> review of the cgroups bits before the core ones are (eventually) merged?
Hello, Patrick.
On Tue, Sep 11, 2018 at 05:26:24PM +0100, Patrick Bellasi wrote:
> My question is: IF the scheduler maintainers are going to be happy
> with the overall design for the core bits, are you happy to start the
> review of the cgroups bits before the core ones are (eventually) merged?
On 11-Sep 08:18, Tejun Heo wrote:
> Hello, Patrick.
Hi Tejun,
> Can we first concentrate on getting in the non-cgroup part first?
That's the reason why I've reordered (as per your request) the series
to have all the core and non-cgroup related bits at the beginning.
There are a couple of
On 11-Sep 08:18, Tejun Heo wrote:
> Hello, Patrick.
Hi Tejun,
> Can we first concentrate on getting in the non-cgroup part first?
That's the reason why I've reordered (as per your request) the series
to have all the core and non-cgroup related bits at the beginning.
There are a couple of
Hello, Patrick.
Can we first concentrate on getting in the non-cgroup part first? The
feature has to make sense without cgroup too and I think it'd be a lot
easier to discuss cgroup details once the scheduler core side is
settled.
Thanks.
--
tejun
Hello, Patrick.
Can we first concentrate on getting in the non-cgroup part first? The
feature has to make sense without cgroup too and I think it'd be a lot
easier to discuss cgroup details once the scheduler core side is
settled.
Thanks.
--
tejun
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still are (potentially) constrained based on parent's assigned
resources. This requires to properly propagate and aggregate parent
attributes
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still are (potentially) constrained based on parent's assigned
resources. This requires to properly propagate and aggregate parent
attributes
14 matches
Mail list logo
