linux-kernel - Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

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: <CAKfTPtAMWbx6m2X8k_px+TK7OGAqgzD+0ShwfNb02xP1O8wg0Q@mail.gmail.com>
Date:   Tue, 23 Aug 2016 15:28:19 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Yuyang Du <yuyang.du@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Paul Turner <pjt@...gle.com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: [PATCH v1 00/10] Optimize sched avgs computation and implement
 flat util hierarchy

On 23 August 2016 at 01:26, Yuyang Du <yuyang.du@...el.com> wrote:
>
> Hi Peter and others,
>
> Could you give this patchset a look?

Hi Yuyang,

I still wonder if using a flat util hierarchy is the right solution to
solve this problem with utilization and task group. I have noticed
exact same issues with load that generates weird task placement
decision and i think that we should probably try to solve both wrong
behavior with same mechanism. but this is not possible with flat
hierarchy for load

Let me take an example.
TA is a always running task on CPU1 in group /root/level1/
TB wakes up on CPU0 and moves TA into group /root/level2/
Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 0.
Then, TB forks a new task TC. TC will probably be schedule on CPU1
because its root cfs_rq's runnable_load_avg is null and CPU1 is the
next CPU after CPU0

Similar behavior can happen when TA migrates

Beside flat utilization consideration, i'm going to have a look at the
optimization part

Regards,
Vincent

>
>
> Thanks,
> Yuyang
>
> On Wed, Aug 10, 2016 at 08:23:52AM +0800, Yuyang Du wrote:
> > On Wed, Aug 10, 2016 at 08:14:45AM +0800, Yuyang Du wrote:
> > > Hi Peter,
> > >
> > > I should have sent out my flat util hierarchy implementation long time ago,
> > > actually code was there but not rebased. I finally have time to do this,
> > > so here it is. There are also other proposals to solve migrated tasks' util
> > > mobility problem, such as the ones from Dietmar and Vincent.
> > >
> > > The sched avgs computation optimization was initiated for the flat util thing,
> > > so I send them out together.
> > >
> > > According to Morten and Ben's feedback, I removed 32-bit as a period's upper
> > > bound limit. So, thanks a lot to them.
> > >
> >
> > To compare the effectiveness of the flat util hierarchy, a simple experiment
> > was done: rt-app to generate a 50% duty-cycling workload (100us/200us), and
> > in the meantime a script to set the CPU affinity of the task, alternating
> > to taskset the task to run on CPU x and CPU y every 0.3 sec, so forcing the
> > task to ping-pong migrate. By auto-group and ssh itself, the task under test
> > is at the third level task group.
> >
> > So compare the top cfs_rq's util_avg (group_hierarchy.jpg) vs. the rq's util_avg
> > (flat_hierarchy.jpg)
> >
> > Thanks,
> > Yuyang
>
>
>