On 04-02-16, 19:18, Rafael J. Wysocki wrote:
On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan skannan@codeaurora.org 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 :(