From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752590AbbCWNj7 (ORCPT ); Mon, 23 Mar 2015 09:39:59 -0400 Received: from casper.infradead.org ([85.118.1.10]:55991 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751873AbbCWNj5 (ORCPT ); Mon, 23 Mar 2015 09:39:57 -0400 Date: Mon, 23 Mar 2015 14:39:44 +0100 From: Peter Zijlstra To: Morten Rasmussen Cc: mingo@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, yuyang.du@intel.com, preeti@linux.vnet.ibm.com, mturquette@linaro.org, nico@linaro.org, rjw@rjwysocki.net, juri.lelli@arm.com, linux-kernel@vger.kernel.org, Russell King Subject: Re: [RFCv3 PATCH 14/48] arm: Frequency invariant scheduler load-tracking support Message-ID: <20150323133944.GG23123@twins.programming.kicks-ass.net> References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <1423074685-6336-15-git-send-email-morten.rasmussen@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1423074685-6336-15-git-send-email-morten.rasmussen@arm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 04, 2015 at 06:30:51PM +0000, Morten Rasmussen wrote: > +/* cpufreq callback function setting current cpu frequency */ > +void arch_scale_set_curr_freq(int cpu, unsigned long freq) > +{ > + atomic_long_set(&per_cpu(cpu_curr_freq, cpu), freq); > +} > + > +/* cpufreq callback function setting max cpu frequency */ > +void arch_scale_set_max_freq(int cpu, unsigned long freq) > +{ > + atomic_long_set(&per_cpu(cpu_max_freq, cpu), freq); > +} > + > +unsigned long arch_scale_freq_capacity(struct sched_domain *sd, int cpu) > +{ > + unsigned long curr = atomic_long_read(&per_cpu(cpu_curr_freq, cpu)); > + unsigned long max = atomic_long_read(&per_cpu(cpu_max_freq, cpu)); > + > + if (!curr || !max) > + return SCHED_CAPACITY_SCALE; > + > + return (curr * SCHED_CAPACITY_SCALE) / max; > +} so I've no idea how many cycles an (integer) division takes on ARM; but doesn't it make sense to do this division (once) in arch_scale_set_curr_freq() instead of every time we need the result?