From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934083AbcBDFky (ORCPT ); Thu, 4 Feb 2016 00:40:54 -0500 Received: from mail-pf0-f179.google.com ([209.85.192.179]:36353 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751081AbcBDFkx (ORCPT ); Thu, 4 Feb 2016 00:40:53 -0500 Date: Thu, 4 Feb 2016 11:10:49 +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 0/11] cpufreq: governor: ondemand/conservative data structures rework Message-ID: <20160204054049.GX3469@vireshk> References: <3705929.bslqXH980s@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3705929.bslqXH980s@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 04-02-16, 00:12, Rafael J. Wysocki wrote: > Hi, > > A few days ago I looked at the common code used by the ondemand and conservative > governors because of the deadlock issue that Viresh has addressed recently > (http://marc.info/?l=linux-pm&m=145450832814058&w=4) and it occurred to me > that the whole thing was really too tangled and might be made easier to follow > at least. I started to work on this and ended up with the following series. > > I'm not really going to stop here, but first, I'd like to let everybody know > that this is happening and second, I'll need to rebase these patches on the > ones from Viresh (in the series linked above), but that may take some time > and I don't want to sit on them for all that long. > > Overall, I'd like the governor code to be cleaner and easier to follow, so we can > move at least some parts of governor work to utilization update callbacks (invoked > by the scheduler) or to at least to irq_work so as to reduce the usage of process > context in cpufreq to absolute minimum. That's the plan for the future, but for > now this is just a major cleanup. > > [1/11] Clean up the way in which the default and fallback governors are set up. > [2/11] Use a common global mutex for dbs_data protection. > [3/11] Use common global pointer to dbs_data for system-wide governors. Hi Rafael, I have some very basic doubts on 2nd and 3rd patch, and so have stopped reviewing after that because there is too much dependency I believe on these two. I will review the rest, if my concerns on the earlier ones are incorrect. -- viresh