From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751604AbcDUCUW (ORCPT ); Wed, 20 Apr 2016 22:20:22 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35222 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751285AbcDUCUT (ORCPT ); Wed, 20 Apr 2016 22:20:19 -0400 From: Steve Muckle X-Google-Original-From: Steve Muckle Date: Wed, 20 Apr 2016 19:20:15 -0700 To: "Rafael J. Wysocki" Cc: Steve Muckle , "Rafael J. Wysocki" , Viresh Kumar , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette Subject: Re: [RFC PATCH 3/4] intel_pstate: support scheduler cpufreq callbacks on remote CPUs Message-ID: <20160421022015.GA10028@sky.smuckle.net> References: <1461119969-10371-1-git-send-email-smuckle@linaro.org> <1461119969-10371-3-git-send-email-smuckle@linaro.org> <48732338.GBX16FRDRa@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <48732338.GBX16FRDRa@vostro.rjw.lan> 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 Wed, Apr 20, 2016 at 02:37:18PM +0200, Rafael J. Wysocki wrote: ... > > @@ -1173,20 +1179,88 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) > > get_avg_frequency(cpu)); > > } > > > > +static void _intel_pstate_update_util(struct cpudata *cpu, u64 time) > > What about calling this intel_pstate_update_cpu()? Sure will change. ... > > static void intel_pstate_update_util(struct update_util_data *data, u64 time, > > unsigned long util, unsigned long max) > > { > > struct cpudata *cpu = container_of(data, struct cpudata, update_util); > > - u64 delta_ns = time - cpu->sample.time; > > + s64 delta_ns = time - cpu->sample.time; > > > > - if ((s64)delta_ns >= pid_params.sample_rate_ns) { > > - bool sample_taken = intel_pstate_sample(cpu, time); > > + if (delta_ns < pid_params.sample_rate_ns) > > Why don't you check cpu->ipi_in_progress here too and bail out if it is set? > > That would allow you to avoid checking the time again below, woulnd't it? Yeah I think that should work. I can't recall why I thought I needed to check the time first, then ipi_in_progress, then the time. As long as ipi_in_progress is checked prior to the time, it should be fine. > > > + return; > > > > - if (sample_taken && !hwp_active) > > - intel_pstate_adjust_busy_pstate(cpu); > > + if (cpu->cpu == smp_processor_id()) { > > + _intel_pstate_update_util(cpu, time); > > + } else { > > + /* The target CPU's rq lock is held. */ > > + if (cpu->ipi_in_progress) > > + return; > > + > > + /* Re-check sample_time which may have advanced. */ > > + smp_rmb(); > > + delta_ns = time - READ_ONCE(cpu->sample.time); > > + if (delta_ns < pid_params.sample_rate_ns) > > + return; > > + > > + cpu->ipi_in_progress = true; > > + cpu->time = time; > > + irq_work_queue_on(&cpu->irq_work, cpu->cpu); > > } > > } > > > > +static inline void intel_pstate_irq_work_sync(unsigned int cpu) > > +{ > > + irq_work_sync(&all_cpu_data[cpu]->irq_work); > > +} > > + > > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu) > > +{ > > + init_irq_work(&cpu->irq_work, intel_pstate_update_util_remote); > > +} > > +#else /* !CONFIG_SMP */ > > +static inline void intel_pstate_irq_work_sync(unsigned int cpu) {} > > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu) {} > > + > > +static void intel_pstate_update_util(struct update_util_data *data, u64 time, > > + unsigned long util, unsigned long max) > > +{ > > + struct cpudata *cpu = container_of(data, struct cpudata, update_util); > > + s64 delta_ns = time - cpu->sample.time; > > + > > + if (delta_ns < pid_params.sample_rate_ns) > > + return; > > + > > + _intel_pstate_update_util(cpu, time); > > +} > > +#endif > > + > > + > > + > > The additional two empty lines are not necessary. > Sorry yeah these were unintentional, will remove these and the ones below. Thanks for the review. thanks, Steve