Re: [PATCH] sched/fair: Update rq_clock, cfs_rq before migrating for asym cpu capacity

[Chris Redpath]

On 09/07/2019 16:36, Vincent Guittot wrote:
> Hi Chris,
>
> > We enter this code quite often in our testing, most individual runs of a
> > test which has small tasks involved have at least one hit where we make
> > a change to the clock with this patch in.
>
> Do you have a rt-app file that you can share ?

The ThreeSmallTasks test which is the worst hit produces this:

{
    "tasks": {
        "small_0": {
            "policy": "SCHED_OTHER",
            "delay": 0,
            "loop": 1,
            "phases": {
                "p000001": {
                    "loop": 62,
                    "run": 2880,
                    "timer": {
                        "ref": "small_0",
                        "period": 16000
                    }
                }
            }
        },
        "small_1": {
            "policy": "SCHED_OTHER",
            "delay": 0,
            "loop": 1,
            "phases": {
                "p000001": {
                    "loop": 62,
                    "run": 2880,
                    "timer": {
                        "ref": "small_1",
                        "period": 16000
                    }
                }
            }
        },
        "small_2": {
            "policy": "SCHED_OTHER",
            "delay": 0,
            "loop": 1,
            "phases": {
                "p000001": {
                    "loop": 62,
                    "run": 2880,
                    "timer": {
                        "ref": "small_2",
                        "period": 16000
                    }
                }
            }
        }
    },
    "global": {
        "default_policy": "SCHED_OTHER",
        "duration": -1,
        "calibration": 264,
        "logdir": "/root/devlib-target"
    }
}

when I run it

> > That said - despite the relatively high number of hits only about 5% of
> > runs see enough additional energy consumed to trigger a test failure. We
> > do try to keep a quiet system as much as possible and only run for a few
> > seconds so the impact we see in testing is also probably higher than in
> > the real world.
>
> Yeah, I'm curious to see the impact on a real system which have a
> 60fps screen update like an android phone

I wouldn't expect much change there but I would on the idle-ish 
homescreen/day-of-use type benchmarks.

If I had a platform with any kind of representative energy use, I'd test 
it :)