From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753693AbcBGJbT (ORCPT ); Sun, 7 Feb 2016 04:31:19 -0500 Received: from mail-pf0-f172.google.com ([209.85.192.172]:35966 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364AbcBGJbQ (ORCPT ); Sun, 7 Feb 2016 04:31:16 -0500 Date: Sun, 7 Feb 2016 15:01:12 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Linux PM list , Linux Kernel Mailing List , Srinivas Pandruvada , Juri Lelli , Steve Muckle , Saravana Kannan Subject: Re: [PATCH v2 2/10] cpufreq: governor: Use common mutex for dbs_data protection Message-ID: <20160207093112.GB19059@vireshk> References: <3705929.bslqXH980s@vostro.rjw.lan> <76588769.1gWBaNHTiQ@vostro.rjw.lan> <20160205065341.GE21792@vireshk> <4787292.dQnn9ZTm9B@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4787292.dQnn9ZTm9B@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05-02-16, 23:59, Rafael J. Wysocki wrote: > One more observation here. > > If we are able to eliminate dbs_data_mutex from update_sampling_rate(), > then cpufreq_governor_dbs() becomes the only user of that lock. Further, > if we can guarantee that the governor's ->governor callback will always > be invoked under policy->rwsem, dbs_data_mutex becomes unnecessary and > may be dropped. That will be guaranteed with my 7 patches, which I will rebase and send again. But there are cases where a single dbs_data is going to be used for multiple policies and so relying on policy->rwsem isn't going to be sufficient. But, yeah, we should be able to narrow down the locked area I believe. -- viresh