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: <20180502140226.GU12217@hirez.programming.kicks-ass.net>
Date:   Wed, 2 May 2018 16:02:26 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     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,
        Mike Galbraith <efault@....de>, 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, 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.

Or suppose B has siblings and each group at that level is a delegate to
a particular user/container. And the user/container in B happens to need
2 partitioned VMs or whatever.

The idea is the same in all the examples, you want to allow
sub-partitions.