linux-kernel - Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

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: <20171011160208.ebt6z6vf5ccefsky@hirez.programming.kicks-ass.net>
Date:   Wed, 11 Oct 2017 18:02:08 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:     mingo@...hat.com, tj@...nel.org, vbabka@...e.cz,
        lizefan@...wei.com, akpm@...ux-foundation.org,
        weiyongjun1@...wei.com, juri.lelli@....com, rostedt@...dmis.org,
        claudio@...dence.eu.com, luca.abeni@...tannapisa.it,
        bristot@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

On Wed, Aug 16, 2017 at 03:20:36PM -0600, Mathieu Poirier wrote:

> In this set the problem is addressed by relying on existing list of tasks
> (sleeping or not) already maintained by CPUsets. 

Right, that's a much saner approach :-)

> OPEN ISSUE:
> 
> Regardless of how we proceed (using existing CPUset list or new ones) we
> need to deal with DL tasks that span more than one root domain,  something
> that will typically happen after a CPUset operation.  For example, if we
> split the number of available CPUs on a system in two CPUsets and then turn
> off the 'sched_load_balance' flag on the parent CPUset, DL tasks in the
> parent CPUset will end up spanning two root domains.
> 
> One way to deal with this is to prevent CPUset operations from happening
> when such condition is detected, as enacted in this set.  Although simple
> this approach feels brittle and akin to a "whack-a-mole" game.  A better
> and more reliable approach would be to teach the DL scheduler to deal with
> tasks that span multiple root domains, a serious and substantial
> undertaking.
> 
> I am sending this as a starting point for discussion.  I would be grateful
> if you could take the time to comment on the approach and most importantly
> provide input on how to deal with the open issue underlined above.

Right, so teaching DEADLINE about arbitrary affinities is 'interesting'.

Although the rules proposed by Tomasso; if found sufficient; would
greatly simplify things. Also the online semi-partition approach to SMP
could help with that.

But yes, that's fairly massive surgery. For now I think we'll have to
live and accept the limitations. So failing the various cpuset
operations when they violate rules seems fine. Relaxing rules is always
easier than tightening them (later).

One 'series' you might be interested in when respinning these is:

  https://lkml.kernel.org/r/20171011094833.pdp4torvotvjdmkt@hirez.programming.kicks-ass.net

By doing synchronous domain rebuild we loose a bunch of funnies.