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
| ||
|
Date: Mon, 28 Aug 2017 08:10:23 +0200 From: Mike Galbraith <efault@....de> To: Joel Fernandes <joelaf@...gle.com> 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 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 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 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) -Mike
Powered by blists - more mailing lists