Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753463AbdLMQXM (ORCPT ); Wed, 13 Dec 2017 11:23:12 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59798 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbdLMQXH (ORCPT ); Wed, 13 Dec 2017 11:23:07 -0500 Date: Wed, 13 Dec 2017 16:23:02 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Subject: Re: [PATCH v2 0/4] Utilization estimation (util_est) for FAIR tasks Message-ID: <20171213162302.GC8264@e110439-lin> References: <20171205171018.9203-1-patrick.bellasi@arm.com> <20171213160357.3se4vvyo5lqud2uo@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171213160357.3se4vvyo5lqud2uo@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1360 Lines: 37 On 13-Dec 17:03, Peter Zijlstra wrote: > On Tue, Dec 05, 2017 at 05:10:14PM +0000, Patrick Bellasi wrote: > > With this feature enabled, the measured overhead is in the range of ~1% > > on the same HW/SW test configuration. > > That's quite a lot; did you look where that comes from? I've tracked it down to util_est_dequeue() introduced by PATCH 2/4, mainly due to the EWMA udpate. Initially the running average was implemented using the library function provided in: include/linux/average.h::DECLARE_EWMA but that solution generated even more overhead. That's why we switched to an "inline custom" implementation. Hackbench is quite stressful for that path and we have also few branches which can play a role. One for example has been added to avoid the EWMA if the rolling average is "close enough" to the current PELT value. All that considered, that's why I disable by default the sched_feat, in which case we have 0 overheads... in !SCHED_DEBUG kernel the code is actually removed by the compiler. In mobile systems (i.e. non-hackbench scenarios) the additional benefits on tasks placement and OPP selection is likely still worth the overhead. Do you think the idea to have a Kconfig to enabled this feature only on systems which do not care about the possible overheads is a viable solution? -- #include Patrick Bellasi