Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751135AbdFAMWc (ORCPT ); Thu, 1 Jun 2017 08:22:32 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:38724 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbdFAMWb (ORCPT ); Thu, 1 Jun 2017 08:22:31 -0400 Date: Thu, 1 Jun 2017 14:22:24 +0200 From: Peter Zijlstra To: Viresh Kumar Cc: Ingo Molnar , Rafael Wysocki , linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, Vincent Guittot , linux-pm@vger.kernel.org, Juri Lelli , Dietmar.Eggemann@arm.com, Morten.Rasmussen@arm.com Subject: Re: [RFC] sched: fair: Don't update CPU frequency too frequently Message-ID: <20170601122224.c324h4t7y3i4wr6e@hirez.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 496 Lines: 10 On Thu, Jun 01, 2017 at 05:04:27PM +0530, Viresh Kumar wrote: > This patch relocates the call to utilization hook from > update_cfs_rq_load_avg() to task_tick_fair(). That's not right. Consider hardware where 'setting' the DVFS is a 'cheap' MSR write, doing that once every 10ms (HZ=100) is absurd. We spoke about this problem in Pisa, the proposed solution was having each driver provide a cost metric and the generic code doing a max filter over the window constructed from that cost metric.