| Message ID | 1367271946-7239-4-git-send-email-ccross@android.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Mon 2013-04-29 14:45:39, Colin Cross wrote: > Freezing tasks will wake up almost every userspace task from > where it is blocking and force it to run until it hits a > call to try_to_sleep(), generally on the exit path from the syscall > it is blocking in. On resume each task will run again, usually > restarting the syscall and running until it hits the same > blocking call as it was originally blocked in. Ok, so you are optimizing suspend at the cost of runtime operations, right? Would it make sense to do suspends entirely without freezer in your configurations? With the right drivers, it should work ok. Actually, would it make sense to simply enter deep idle and do runtime powersaving in the drivers... n900 does that rather successfully and it is certainly cleaner design. > +/* Like schedule_timeout(), but should not block the freezer. */ > +#define freezable_schedule_timeout(timeout) \ > +({ \ > + long __retval; \ > + freezer_do_not_count(); \ > + __retval = schedule_timeout(timeout); \ > + freezer_count(); \ > + __retval; \ > +}) You plan to use this a lot during normal operation, right? Is it going to have some measureable impact? Also, why not static inline? Pavel
On Thursday 02 May 2013 14:48:26 Pavel Machek wrote: > On Mon 2013-04-29 14:45:39, Colin Cross wrote: > > Freezing tasks will wake up almost every userspace task from > > where it is blocking and force it to run until it hits a > > call to try_to_sleep(), generally on the exit path from the syscall > > it is blocking in. On resume each task will run again, usually > > restarting the syscall and running until it hits the same > > blocking call as it was originally blocked in. > > Ok, so you are optimizing suspend at the cost of runtime operations, > right? > > Would it make sense to do suspends entirely without freezer in your > configurations? With the right drivers, it should work ok. Right now drivers now that they will not be busy when runtime suspend happens. The freezer has the same effect for system PM. If you remove that certainty it becomes impossible for simple drivers to declare their devices busy upon open and do no synchronization between IO and PM. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 2013-05-02 15:05:13, Oliver Neukum wrote: > On Thursday 02 May 2013 14:48:26 Pavel Machek wrote: > > On Mon 2013-04-29 14:45:39, Colin Cross wrote: > > > Freezing tasks will wake up almost every userspace task from > > > where it is blocking and force it to run until it hits a > > > call to try_to_sleep(), generally on the exit path from the syscall > > > it is blocking in. On resume each task will run again, usually > > > restarting the syscall and running until it hits the same > > > blocking call as it was originally blocked in. > > > > Ok, so you are optimizing suspend at the cost of runtime operations, > > right? > > > > Would it make sense to do suspends entirely without freezer in your > > configurations? With the right drivers, it should work ok. > > Right now drivers now that they will not be busy when runtime > suspend happens. The freezer has the same effect for system PM. > If you remove that certainty it becomes impossible for simple drivers > to declare their devices busy upon open and do no synchronization > between IO and PM. I know. Drivers can mostly ignore suspend. But android people do suspend multiple times a second, and are optimizing freezer. I'm suggesting they should take a look at their drivers, and perhaps they can optimize freezer out totally. (Or perhaps switch to n900-like solution, and avoid suspend entirely. They keep machines functioning in suspend mode. That aint no suspend.) Pavel
On Thu, May 2, 2013 at 5:48 AM, Pavel Machek <pavel@ucw.cz> wrote: > On Mon 2013-04-29 14:45:39, Colin Cross wrote: >> Freezing tasks will wake up almost every userspace task from >> where it is blocking and force it to run until it hits a >> call to try_to_sleep(), generally on the exit path from the syscall >> it is blocking in. On resume each task will run again, usually >> restarting the syscall and running until it hits the same >> blocking call as it was originally blocked in. > > Ok, so you are optimizing suspend at the cost of runtime operations, > right? The runtime operations are negligible, it is setting a bit before blocking, and then clearing the bit and checking a single global counter as the fast-path after blocking. Both will be lost in the noise of the context switch that is happening. > Would it make sense to do suspends entirely without freezer in your > configurations? With the right drivers, it should work ok. No, we need userspace tasks to freeze. That is one of the main reasons we go to suspend, to prevent recurring timers from firing. > Actually, would it make sense to simply enter deep idle and do runtime > powersaving in the drivers... n900 does that rather successfully and > it is certainly cleaner design. It depends on the SoC if that is even possible, and if we did do it we would still use cgroup freezers to prevent apps from running and eating the battery so this patch would still be applicable. >> +/* Like schedule_timeout(), but should not block the freezer. */ >> +#define freezable_schedule_timeout(timeout) \ >> +({ \ >> + long __retval; \ >> + freezer_do_not_count(); \ >> + __retval = schedule_timeout(timeout); \ >> + freezer_count(); \ >> + __retval; \ >> +}) > > You plan to use this a lot during normal operation, right? Is it going > to have some measureable impact? It has a very measurable impact on suspend/resume operations (reducing freeze time by a factor of 10, reducing context switches from 1000 to 25). I haven't measured the impact on total energy used for a suspend/resume cycle, but based on previous measurements I expect it to be beneficial. > Also, why not static inline? I copied the style of the existing helpers. I can change them all to static inlines if you prefer. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > > Also, why not static inline? > > I copied the style of the existing helpers. I can change them all to > static inlines if you prefer. That would be better, yes. Pavel
diff --git a/include/linux/freezer.h b/include/linux/freezer.h index e70df40..b239f45 100644 --- a/include/linux/freezer.h +++ b/include/linux/freezer.h @@ -152,6 +152,26 @@ static inline bool freezer_should_skip(struct task_struct *p) freezer_count(); \ }) +/* Like schedule_timeout(), but should not block the freezer. */ +#define freezable_schedule_timeout(timeout) \ +({ \ + long __retval; \ + freezer_do_not_count(); \ + __retval = schedule_timeout(timeout); \ + freezer_count(); \ + __retval; \ +}) + +/* Like schedule_timeout_interruptible(), but should not block the freezer. */ +#define freezable_schedule_timeout_interruptible(timeout) \ +({ \ + long __retval; \ + freezer_do_not_count(); \ + __retval = schedule_timeout_interruptible(timeout); \ + freezer_count(); \ + __retval; \ +}) + /* Like schedule_timeout_killable(), but should not block the freezer. */ #define freezable_schedule_timeout_killable(timeout) \ ({ \ @@ -162,6 +182,17 @@ static inline bool freezer_should_skip(struct task_struct *p) __retval; \ }) +/* Like schedule_hrtimeout_range(), but should not block the freezer. */ +#define freezable_schedule_hrtimeout_range(expires, delta, mode) \ +({ \ + int __retval; \ + freezer_do_not_count(); \ + __retval = schedule_hrtimeout_range(expires, delta, mode); \ + freezer_count(); \ + __retval; \ +}) + + /* * Freezer-friendly wrappers around wait_event_interruptible(), * wait_event_killable() and wait_event_interruptible_timeout(), originally @@ -180,30 +211,32 @@ static inline bool freezer_should_skip(struct task_struct *p) #define wait_event_freezable(wq, condition) \ ({ \ int __retval; \ - for (;;) { \ - __retval = wait_event_interruptible(wq, \ - (condition) || freezing(current)); \ - if (__retval || (condition)) \ - break; \ - try_to_freeze(); \ - } \ + freezer_do_not_count(); \ + __retval = wait_event_interruptible(wq, (condition)); \ + freezer_count(); \ __retval; \ }) #define wait_event_freezable_timeout(wq, condition, timeout) \ ({ \ long __retval = timeout; \ - for (;;) { \ - __retval = wait_event_interruptible_timeout(wq, \ - (condition) || freezing(current), \ + freezer_do_not_count(); \ + __retval = wait_event_interruptible_timeout(wq, (condition), \ __retval); \ - if (__retval <= 0 || (condition)) \ - break; \ - try_to_freeze(); \ - } \ + freezer_count(); \ __retval; \ }) +#define wait_event_freezable_exclusive(wq, condition) \ +({ \ + int __retval; \ + freezer_do_not_count(); \ + __retval = wait_event_interruptible_exclusive(wq, condition); \ + freezer_count(); \ + __retval; \ +}) + + #else /* !CONFIG_FREEZER */ static inline bool frozen(struct task_struct *p) { return false; } static inline bool freezing(struct task_struct *p) { return false; } @@ -225,15 +258,26 @@ static inline void set_freezable(void) {} #define freezable_schedule() schedule() +#define freezable_schedule_timeout(timeout) schedule_timeout(timeout) + +#define freezable_schedule_timeout_interruptible(timeout) \ + schedule_timeout_interruptible(timeout) + #define freezable_schedule_timeout_killable(timeout) \ schedule_timeout_killable(timeout) +#define freezable_schedule_hrtimeout_range(expires, delta, mode) \ + schedule_hrtimeout_range(expires, delta, mode) + #define wait_event_freezable(wq, condition) \ wait_event_interruptible(wq, condition) #define wait_event_freezable_timeout(wq, condition, timeout) \ wait_event_interruptible_timeout(wq, condition, timeout) +#define wait_event_freezable_exclusive(wq, condition) \ + wait_event_interruptible_exclusive(wq, condition) + #define wait_event_freezekillable(wq, condition) \ wait_event_killable(wq, condition)
Freezing tasks will wake up almost every userspace task from where it is blocking and force it to run until it hits a call to try_to_sleep(), generally on the exit path from the syscall it is blocking in. On resume each task will run again, usually restarting the syscall and running until it hits the same blocking call as it was originally blocked in. To allow tasks to avoid running on every suspend/resume cycle, this patch adds additional freezable wrappers around blocking calls that call freezer_do_not_count(). Combined with the previous patch, these tasks will not run during suspend or resume unless they wake up for another reason, in which case they will run until they hit the try_to_freeze() in freezer_count(), and then continue processing the wakeup after tasks are thawed. This patch also converts the existing wait_event_freezable* wrappers to use freezer_do_not_count(). Additional patches will convert the most common locations that userspace blocks in to use freezable helpers. Signed-off-by: Colin Cross <ccross@android.com> --- include/linux/freezer.h | 72 +++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 58 insertions(+), 14 deletions(-)