From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754294AbdCBReX (ORCPT ); Thu, 2 Mar 2017 12:34:23 -0500 Received: from foss.arm.com ([217.140.101.70]:34236 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754036AbdCBReV (ORCPT ); Thu, 2 Mar 2017 12:34:21 -0500 Date: Thu, 2 Mar 2017 17:11:39 +0000 From: Patrick Bellasi To: Vincent Guittot Cc: linux-kernel , "linux-pm@vger.kernel.org" , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Steven Rostedt , John Stultz , Juri Lelli , Todd Kjos , Tim Murray , Andres Oportus , Joel Fernandes , Morten Rasmussen , Dietmar Eggemann , Chris Redpath Subject: Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Message-ID: <20170302171139.GE28760@e110439-lin> References: <1488469507-32463-1-git-send-email-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On 02-Mar 17:09, Vincent Guittot wrote: > On 2 March 2017 at 16:45, Patrick Bellasi wrote: > > The current version of schedutil has some issues related to the management > > of update flags used by systems with frequency domains spawning multiple CPUs. > > > > Each time a CPU utilisation update is issued by the scheduler a set of flags > > are configured to define (mainly) which class is asking for a utilisation > > update. These flags are then used by the frequency selection policy to > > identify the OPP to choose. > > > > In the current implementation, CPU flags are overridden each time the > > scheduler calls schedutil for an update. Such a behaviour produces issues > > in these scenarios, where we assume CPU1 and CPU2 share the same frequency > > domain: > > a) a RT task which executed on CPU1 can keep the domain at an high frequency > > for a long period of time, even if there are no longer RT tasks on > > CPUs in that domain > > Normally this is dropped after a tick. > Nevertheless, there is an issue if the freq_update_delay_ns is shorter > than a tick because of sugov RT thread Indeed, I've noticed that a small FAIR task running on CPU2 is quite likely to be running at an higher OPP just because on the other CPU of the same frequency domain (i.e. CPU1) sometimes we have the sugov RT thread running. In this case, the RT flag in CPU1 is never cleared when that core is always idle but for the execution of the sugov thread. -- #include Patrick Bellasi