On 04-02-16, 19:18, Rafael J. Wysocki wrote: > On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan <[email protected]> > 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
