From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753160AbcBHMwe (ORCPT <rfc822;w@1wt.eu>);
	Mon, 8 Feb 2016 07:52:34 -0500
Received: from mail-lb0-f193.google.com ([209.85.217.193]:35794 "EHLO
	mail-lb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752987AbcBHMwa (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 8 Feb 2016 07:52:30 -0500
MIME-Version: 1.0
In-Reply-To: <20160208115248.GC8294@vireshk>
References: <3071836.JbNxX8hU6x@vostro.rjw.lan>
	<20160207091040.GA6112@vireshk>
	<1855005.ZFAA5ekheo@vostro.rjw.lan>
	<2172360.cldhrkXzeh@vostro.rjw.lan>
	<20160208115248.GC8294@vireshk>
Date: Mon, 8 Feb 2016 13:52:28 +0100
X-Google-Sender-Auth: gWL6WmPaVE_9wVpbj8qX3oZnFW8
Message-ID: <CAJZ5v0gVffRb33CJcrTY5KEPY04MQNp=uqsGFwMevZAEuYBGfg@mail.gmail.com>
Subject: Re: [PATCH 3/3 v3] cpufreq: governor: Replace timers with utilization
 update callbacks
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Linux PM list <linux-pm@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Juri Lelli <juri.lelli@arm.com>,
        Steve Muckle <steve.muckle@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 8, 2016 at 12:52 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 08-02-16, 03:08, Rafael J. Wysocki wrote:
>> Moreover, update_sampling_rate() doesn't need to walk the cpu_dbs_infos,
>> it may walk policies instead.  Like after the (untested) appended patch.
>>
>> Then, if we have a governor_data_lock in struct policy, we can use that
>> to protect policy_dbs while it is being access there and we're done.
>>
>> I'll try to prototype something along these lines tomorrow.
>
> I have solved that in a different way, and dropped the lock from
> update_sampling_rate(). Please see if that looks good.

Well, almost.

I like the list approach, but you need to be careful about it.  Let me
comment more on the patches in the series.

I have a gut feeling that my idea of walking policies will end up
being simpler in the end, but let's see. :-)

Thanks,
Rafael