linux-kernel - Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load

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: <1525271702.4975.3.camel@gmx.de>
Date:   Wed, 02 May 2018 16:35:02 +0200
From:   Mike Galbraith <efault@....de>
To:     Peter Zijlstra <peterz@...radead.org>,
        Waiman Long <longman@...hat.com>
Cc:     Tejun Heo <tj@...nel.org>, Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Ingo Molnar <mingo@...hat.com>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        kernel-team@...com, pjt@...gle.com, luto@...capital.net,
        torvalds@...ux-foundation.org, Roman Gushchin <guro@...com>,
        Juri Lelli <juri.lelli@...hat.com>
Subject: Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2

On Wed, 2018-05-02 at 16:02 +0200, Peter Zijlstra wrote:
> On Wed, May 02, 2018 at 09:47:00AM -0400, Waiman Long wrote:
> 
> > > I've read half of the next patch that adds the isolation thing. And
> > > while that kludges around the whole root cgorup is magic thing, it
> > > doesn't help if you move the above scenario on level down:
> > >
> > >
> > > 	R
> > >      /    \
> > >    A        B
> > >           /   \
> > >         C       D
> > >
> > >
> > > R: cpus=0-7, load_balance=0
> > > A: cpus=0-1, load_balance=1
> > > B: cpus=2-7, load_balance=0
> > > C: cpus=2-3, load_balance=1
> > > D: cpus=4-7, load_balance=1
> > >
> > >
> > > Also, I feel we should strive to have a minimal amount of tasks that
> > > cannot be moved out of the root group; the current set is far too large.
> > 
> > What exactly is the use case you have in mind with loading balancing
> > disabled in B, but enabled in C and D? We would like to support some
> > sensible use cases, but not every possible combinations.
> 
> Suppose A is your system group, and C and D are individual RT workloads
> or something.

Yeah, it does have a distinct "640K ought to be enough for anybody"
flavor to it.

	-Mike