Message-ID: <CAJWu+orMvinOhC1YMhnNij6K7szRYW2UgEBde5iuZSGY3RFUbw@mail.gmail.com>
Date:   Mon, 28 Aug 2017 09:20:12 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Mike Galbraith <efault@....de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Josef Bacik <jbacik@...com>, Juri Lelli <Juri.Lelli@....com>,
        Brendan Jackman <brendan.jackman@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Rik van Riel <riel@...hat.com>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag

Hi Mike,

On Sun, Aug 27, 2017 at 11:10 PM, Mike Galbraith <efault@....de> wrote:
> On Sun, 2017-08-27 at 22:27 -0700, Joel Fernandes wrote:
>> Hi Mike,
>>
>> On Sun, Aug 27, 2017 at 11:07 AM, Mike Galbraith <efault@....de> wrote:
>> > On Sat, 2017-08-26 at 23:39 -0700, Joel Fernandes wrote:
>> >>
>> >> Also about real world benchmarks, in Android we have usecases that
>> >> show that the graphics performance and we have risk of frame drops if
>> >> we don't use the sync flag so this is a real world need.
>> >
>> > That likely has everything to do with cpufreq not realizing that your
>> > CPUs really are quite busy when scheduling cross core at fairly high
>> > frequency, and not clocking up properly.
>> >
>>
>> I'm glad you brought this point up. Since Android O, the userspace
>> processes are much more split across procedure calls due to a feature
>> called treble (which does this for security, modularity etc). Due to
>> this, a lot of things that were happening within a process boundary
>> happen now across process boundaries over the binder bus. Early on
>> folks noticed that this caused performance issues without sync flag
>> being used as a more strong hint. This can happen when there are 2
>> threads are in different frequency domains on different CPUs and are
>> communicating over binder, due to this the combined load of both
>> threads is divided between the individual CPUs and causes them to run
>> at lower frequency. Where as if they are running together on the same
>> CPUs, then they would run at a higher frequency and perform better as
>> their combined load would run at a higher frequency. So a stronger
>> sync actually helps this case if we're careful about using it when
>> possible.
>
> Sure, but isn't that really a cpufreq issue?  We schedule cross core

IMO its an issue with the scheduler not being aware of the
relationship between groups of tasks doing work as a pipeline. Sync
seems to me one way to communicate that.

> quite aggressively for obvious reasons.  Now on mostly idle handheld
> devices, you may get better battery life by stacking tasks a bit more,
> in which case a sync-me-harder flag may be what you really want/need,
> but with modern CPUs, I'm kinda skeptical of that, would have to see
> cold hard numbers to become a believer.  Iff deeper cstate etc for

If you can suggest any tests, I could run them on my Intel machine? By
the way CPUs on handhelds are pretty modern these days ;-)

> longer does make a big difference, I can imagine wakeup time migrate
> leftward if capacity exists as an "on battery" tactic. (though that
> thought also invokes some unpleasant bounce fest images)

I'm assuming you mean that tasks are packed together more closely and
scheduled on energy aware CPUs at wake up time. This is exactly what
we do in the Energy aware scheduling (EAS) that ARM has been working
on and is integrated into the Android kernels but its being done
whether on battery or plugged in. Also instead of migrating leftward
or a fixed diretion, it checks for what would the changes in energy be
based on an "energy model" and the current utilization before deciding
on whether to wake up on a different CPU. Its also not perfect and is
an approximation but overall seems to provide good energy savings.

thanks,

-Joel


>
>         -Mike

Powered by blists - more mailing lists