linux-kernel - Re: [PATCH RFC 0/3] sched/fair: cpu time reserves for cgroups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5739BB7E.8010902@yandex-team.ru>
Date:	Mon, 16 May 2016 15:22:22 +0300
From:	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>, cgroups@...r.kernel.org,
	containers@...ts.linux-foundation.org
Subject: Re: [PATCH RFC 0/3] sched/fair: cpu time reserves for cgroups

On 16.05.2016 14:18, Peter Zijlstra wrote:
> On Mon, May 16, 2016 at 12:36:19PM +0300, Konstantin Khlebnikov wrote:
>> This feature allows to change cpu cgroup weight for a limited time.
>>
>> Cgroup interface:
>> cpu.cfs_reserve_us      - reserved time for each cpu.cfs_period_us
>> cpu.cfs_reserve_shares  - group weight during reserved time
>>
>> While cfs group consumes reserved cpu time it has different weight,
>> thus it gets different vruntime penalty for that execution.
>>
>>          ^ weight
>>          |
>>          |
>> reserve |
>> shares  -------*
>>          |      |
>>          |      |
>>          |      |
>> shares  -      *-----------------*
>>          |                        |
>>          |                        |
>>          0------|-----------------|-----------> time
>>                 reserve           quota
>>
>> Reserve can work as a "low limit": boost weight for "guaranteed" time,
>> and as a "high limit": give normal weight for a limited time and allow
>> utilize cpu when nobody else needs it.
>>
>
> You forgot to explain why I should care about this.

As I told this works as low-limit or high-limit which allow to
control cpu time distribution without hard limits and throttling.

Present quota/hard limit has well known problems when it throttle task
inside kernel where it holds mutexes. Also it's too strict and doesn't
allow utilization of unused cpu time.

-- 
Konstantin