Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751660AbdHSR6h (ORCPT ); Sat, 19 Aug 2017 13:58:37 -0400 Received: from mail-qt0-f172.google.com ([209.85.216.172]:33822 "EHLO mail-qt0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751165AbdHSR6f (ORCPT ); Sat, 19 Aug 2017 13:58:35 -0400 MIME-Version: 1.0 In-Reply-To: <1503118674.5112.20.camel@gmx.de> References: <20170818235026.618-1-joelaf@google.com> <1503118674.5112.20.camel@gmx.de> From: Joel Fernandes Date: Sat, 19 Aug 2017 10:58:34 -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: 2141 Lines: 47 Hi Mike, On Fri, Aug 18, 2017 at 9:57 PM, Mike Galbraith wrote: > On Fri, 2017-08-18 at 16:50 -0700, Joel Fernandes wrote: >> The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount >> accumulated during a single update doesn't cross a period boundary. This is >> fine in cases where the amount accrued is much smaller than the size of a >> single PELT window (1ms) however if the amount accrued is high then the >> relative error (calculated against what the actual signal would be had we >> updated the averages) can be high - as much 2% in my testing. On plotting >> signals, I found that there are errors especially high when we update just >> before the period boundary is hit. These errors can be significantly reduced if >> we update the averages more often. >> >> Inorder to fix this, this patch does the average update by also checking how >> much time has elapsed since the last update and update the averages if it has >> been long enough (as a threshold I chose 512us). > > 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. Also about motivation, as I described in previous threads - I didn't nail this down to a particular change in behavior but other patches have been posted before that do things to improve signal accuracy, this is just one step in that direction. thanks, -Joel [1] https://github.com/joelagnel/joelagnel.github.io/blob/master/misc/pelt-error-v4.pdf > > -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. >