linux-kernel - Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJWu+oqSjHFN3nBDJAQanERxxuqQdcer=JvjjuS59B4U_VWstg@mail.gmail.com>
Date:   Sun, 27 Aug 2017 22:27:29 -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: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.

thanks,

-Joel

>         -Mike