Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752733AbdHTGrC (ORCPT ); Sun, 20 Aug 2017 02:47:02 -0400 Received: from mail-qk0-f172.google.com ([209.85.220.172]:34059 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751607AbdHTGrB (ORCPT ); Sun, 20 Aug 2017 02:47:01 -0400 MIME-Version: 1.0 In-Reply-To: <1503208825.12180.125.camel@gmx.de> References: <20170818235026.618-1-joelaf@google.com> <1503118674.5112.20.camel@gmx.de> <1503208825.12180.125.camel@gmx.de> From: Joel Fernandes Date: Sat, 19 Aug 2017 23:46:59 -0700 Message-ID: Subject: Re: [PATCH v2] sched/fair: Make PELT signal more accurate To: Mike Galbraith Cc: LKML , Vincent Guittot , Peter Zijlstra , Juri Lelli , Brendan Jackman , Dietmar Eggeman , kernel-team@android.com, Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2037 Lines: 48 Hi Mike, On Sat, Aug 19, 2017 at 11:00 PM, Mike Galbraith wrote: > On Sat, 2017-08-19 at 10:58 -0700, Joel Fernandes wrote: >> >> > Ok, I gotta ask: In order to fix what? What exactly does the small >> > but existent overhead increase buy us other than an ever so slightly >> > different chart? What is your motivation to care about a microscopic >> > change in signal shape? >> >> I wouldn't call the change "microscopic", its about 2% absolute which >> comes down to 1% with this change (if you count in relative terms, its >> higher and you can see the bump as the signal rises). >> If you look at the first chart at [1] at 3.74, that's not microscopic >> at all to me. > > Whether that 0.02->0.01 is viewed as significant by you or I matters > not at all, for it to be significant, it must have measurable effect. > > Where is the consumer which benefits from precision improvement.. of > the instantaneously wildly inaccurate average. Where is the non-zero > return on investment? If the chart is the entire product, no sale. One thing I want to mention is the overhead shows up only in the one unixbench test that this is sensitive to (and even in that the overhead is around 0.005, its within the noise for large number of runs), for the other tests I ran like hackbench, there wasn't any overhead at all. I am not saying that patch solves a major issue that exists that I know off, but its just an observation while studying the code but I'd argue its still an improvement that's harmless and worthwhile to have. Anyway the study is here for any one to see in the the future and it was indeed useful to me, to learn more about the code. I am Ok with dropping this patch if the general feeling is the inaccurate average is Ok. thanks for your review, -Joel > > -Mike > > -- > You received this message because you are subscribed to the Google Groups "kernel-team" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >