From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751339AbcBECoi (ORCPT ); Thu, 4 Feb 2016 21:44:38 -0500 Received: from mail-pf0-f172.google.com ([209.85.192.172]:34476 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbcBECoc (ORCPT ); Thu, 4 Feb 2016 21:44:32 -0500 Date: Fri, 5 Feb 2016 08:14:28 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Saravana Kannan , Shilpa Bhat , Juri Lelli , Rafael Wysocki , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Peter Zijlstra , Michael Turquette , Steve Muckle , Vincent Guittot , Morten Rasmussen , dietmar.eggemann@arm.com, Linux Kernel Mailing List Subject: Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups Message-ID: <20160205024428.GB3068@vireshk> References: <20160203155428.GY3947@e106622-lin> <20160203161059.GH3469@vireshk> <20160203172009.GC12132@e106622-lin> <20160204110907.GE3469@vireshk> <56B38DC8.8060606@codeaurora.org> <56B38E14.5060705@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 19:18, Rafael J. Wysocki wrote: > On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan wrote: > > On 02/04/2016 09:43 AM, Saravana Kannan wrote: > >> No no no no! Let's not open up this can of worms of queuing up the work > >> to handle a write to a sysfs file. It *MIGHT* work for this specific > >> tunable (I haven't bothered to analyze), but this makes it impossible to > >> return a useful/proper error value. > > > > > > Sent too soon. Not only that, but it can also cause the writes to the sysfs > > files to get processed in a different order and I don't know what other > > issues/races THAT will open up. > > Well, I don't like this too. I expected similar responses only, so no surprises for me :) Though there are few things I would like to tell here: - There wouldn't be any race for updating the file, as that is done directly from store_sampling_rate(). It updates the *real* file we wanted to. - What's offloaded to the work-handler is something very special about ondemand governor and sampling rate. The same is not done for conservative governor as well, don't know why though. - After updating the sampling rate, we assess if we need to reschedule the timers/workqueue to a different time for better efficiency. I don't think there can be a race there and it can be safely done in a work.. > I actually do have an idea about how to fix these deadlocks, but it is > on top of my cleanup series. I would like to hear that, if you can, to save your time. I have tried so many different ways of fixing this yesterday and found issue everywhere :( -- viresh