linux-kernel - Re: [RFC PATCH 2/3] sched/deadline: add task groups bandwidth management support

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: <20180212170920.GM12979@localhost.localdomain>
Date:   Mon, 12 Feb 2018 18:09:20 +0100
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org, tglx@...utronix.de,
        vincent.guittot@...aro.org, rostedt@...dmis.org,
        luca.abeni@...tannapisa.it, claudio@...dence.eu.com,
        tommaso.cucinotta@...tannapisa.it, bristot@...hat.com,
        mathieu.poirier@...aro.org, tkjos@...roid.com, joelaf@...gle.com,
        morten.rasmussen@....com, dietmar.eggemann@....com,
        patrick.bellasi@....com, alessio.balsini@....com
Subject: Re: [RFC PATCH 2/3] sched/deadline: add task groups bandwidth
 management support

Hi,

On 12/02/18 08:47, Tejun Heo wrote:
> Hello,
> 
> On Mon, Feb 12, 2018 at 02:40:29PM +0100, Juri Lelli wrote:
> >  - implementation _is not_ hierarchical: only single/plain DEADLINE entities
> >    can be handled, and they get scheduled at root rq level
> 
> This usually is a deal breaker and often indicates that the cgroup
> filesystem is not the right interface for the feature.  Can you please
> elaborate the interface with some details?

The interface is the same as what we have today for groups of RT tasks,
and same rules apply. The difference is that when using RT
<group>/cpu.rt_runtime_us and <group>/cpu.rt_period_us control
RT-Throttling behaviour (fraction of CPU time and granularity), while
for DEADLINE the same interface would be used only at admission control
time (while servicing a sched_setattr(), attaching tasks to a group or
changing group's parameters) since DEADLINE task have their own
throttling mechanism already.

Intended usage should be very similar. For example, a sys admin that
wants to reserve and guarantee CPU bandwidth for a group of tasks would
create a group, configure its rt_runtime_us, rt_period_us and put
DEADLINE tasks inside it (e.g. video/audio pipeline). Related to what I
was saying in the cover letter (i.e., non root access to DEADLINE
scheduling) might be a different situation, where sys admin wants to
grant a user a certain percentage of CPU time (by creating a group and
putting user session inside it) and also control that user doesn't
exceed what granted. User would then be free to spawn DEADLINE tasks to
service her/his needs up to the maximum bandwidth cap set by sys admin.

Does this make any sense and provide a bit more information?

Thanks a lot for looking at this!

Best,

- Juri