From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033611AbeCARrB (ORCPT ); Thu, 1 Mar 2018 12:47:01 -0500 Received: from foss.arm.com ([217.140.101.70]:42744 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033379AbeCARq6 (ORCPT ); Thu, 1 Mar 2018 12:46:58 -0500 Date: Thu, 1 Mar 2018 17:46:52 +0000 From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Subject: Re: [PATCH v5 4/4] sched/fair: update util_est only on util_avg updates Message-ID: <20180301174652.GB26235@e110439-lin> References: <20180222170153.673-1-patrick.bellasi@arm.com> <20180222170153.673-5-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180222170153.673-5-patrick.bellasi@arm.com> 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 The changelog is missing the below CCs. :( Since that's a new patch in this series, I expect some feedbacks and thus I'll add them on the next respin. On 22-Feb 17:01, Patrick Bellasi wrote: > The estimated utilization of a task is currently updated every time the > task is dequeued. However, to keep overheads under control, PELT signals > are effectively updated at maximum once every 1ms. > > Thus, for really short running tasks, it can happen that their util_avg > value has not been updates since their last enqueue. If such tasks are > also frequently running tasks (e.g. the kind of workload generated by > hackbench) it can also happen that their util_avg is updated only every > few activations. > > This means that updating util_est at every dequeue potentially introduces > not necessary overheads and it's also conceptually wrong if the util_avg > signal has never been updated during a task activation. > > Let's introduce a throttling mechanism on task's util_est updates > to sync them with util_avg updates. To make the solution memory > efficient, both in terms of space and load/store operations, we encode a > synchronization flag into the LSB of util_est.enqueued. > This makes util_est an even values only metric, which is still > considered good enough for its purpose. > The synchronization bit is (re)set by __update_load_avg_se() once the > PELT signal of a task has been updated during its last activation. > > Such a throttling mechanism allows to keep under control util_est > overheads in the wakeup hot path, thus making it a suitable mechanism > which can be enabled also on high-intensity workload systems. > Thus, this now switches on by default the estimation utilization > scheduler feature. > > Suggested-by: Chris Redpath > Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Paul Turner Cc: Vincent Guittot Cc: Morten Rasmussen Cc: Dietmar Eggemann Cc: linux-kernel@vger.kernel.org [...] -- #include Patrick Bellasi