From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751152AbdH1GLL convert rfc822-to-8bit (ORCPT ); Mon, 28 Aug 2017 02:11:11 -0400 Received: from mout.gmx.net ([212.227.15.19]:53243 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbdH1GLK (ORCPT ); Mon, 28 Aug 2017 02:11:10 -0400 Message-ID: <1503900623.6028.33.camel@gmx.de> Subject: Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag From: Mike Galbraith To: Joel Fernandes Cc: LKML , Peter Zijlstra , Josef Bacik , Juri Lelli , Brendan Jackman , Dietmar Eggemann , Matt Fleming , Rik van Riel , Ingo Molnar Date: Mon, 28 Aug 2017 08:10:23 +0200 In-Reply-To: References: <20170827010226.19703-1-joelaf@google.com> <1503812659.7566.43.camel@gmx.de> <1503814090.7566.50.camel@gmx.de> <1503857277.9136.67.camel@gmx.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:yINPXdPNNnnGUJUNaM/UPUGw3EMnIOLJEEtHhAYh2ezOLeJ3yEP dBkGQaGDRLBx4aA1O9Nypgz+DrOqsKbjkejSJzq5NLbGYPYsnA0zc+VKXPmLqBMF56AUAMZ NbDRlSpaMrTMs0VkwESyBziCc26nv4i2PMRhB4hWWR7leKTCP/U1nj0nPGJ+OMs/MNztRw+ crwhrEgfJgvs3AyRE/5Yg== X-UI-Out-Filterresults: notjunk:1;V01:K0:kXdemcYhb5g=:uJ/qQPu/fxDZg6v3b5tkM6 RLsFuCmZpirAZ4ViBVlOkBRXSxNS5jQwoROJoNMzYde7bDUDYkjWVgzoPJS9DfJ88KrgpGzXY WuFenEQkz/vDh7O+K7qAj9QuFBNRPpAj8mmDlsHNklXeRWpJtc6TFWxJpwSZY5g4Vkch72Zed VSiSX+QVXQmzqvOqtjqiuXlS3rjAOJTDmwjvw0StsFN3TS4x38K+V19piVWiPyrGysaXGNep5 l2+5ApER3UkP2lz7tS/EcEdAKfqvIEAw9EiMAPE5SmxCoUyiYnl8sqyHPqS1Wb62wzYWumg8s wU1Qhk3cfSZhCY63ZvrB1+S0sMDUzEnHOtW2d49i6IX71RdKETBVmotjUzUPC92OKz5b6I7sw HVTWGyfg9OqY76k81/llsUbU+8eKZHeUfgUQqBQYFTlHZ6XCiLHPdGy3mZXm52GB+vmfv7D/U vv5jJCljHnuHM2RjRvHB1VAeRkEpWN9oneIvkV2Lkn6+mD5o3z4jYrM653bm5rk3e79i1EIwx I1H1li3FVm2wO2gcvj1SRRTfwJbGbbqXOp0j9TDXlOztCUUsrz/dyvxF4A6A0D4M5Vzk4rrwd JW6k6R3QsurrhdzBthAdi2K8dlJNJMRf/Yv37ytoJTqJceYP3ZS27nJm2yf8qfxZIrSJMlf2v WajpWSyvHIf93r2UniWEqWuekmzwEsXR30JhSYMfBAleaA3Od/9KBNJVxFo1ANGqNa3h2yhCi 0eeY2JUqa4e5X5ntDp0oPzY7M+sNsk260lPbx0/DB0Rdc/sxgpClNeFWd79DQhvuYwxYYLfNo JZ4zUPSlpXgKZ/dwfzyyRA9nmZlWar1ASEcEsOjZ2/rPnANy0Q= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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