PM: Opportunistic suspend support.
in [Kernel]
|
Prev: direct-io: do not merge logically non-contiguous requests
Next: [PATCH] linux/elfcore.h: hide kernel functions
From: Rafael J. Wysocki on 27 May 2010 16:00 On Thursday 27 May 2010, Dmitry Torokhov wrote: > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hj�nnev�g wrote: > > 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: > > > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > > > > > >> > I must be missing something. In Arve's patch 1/8, if the system is in > > >> > opportunistic suspend, and a wakeup event occurs but no suspend > > >> > blockers get enabled by the handler, what causes the system to go back > > >> > into suspend after the event is handled? Isn't that a loop of some > > >> > sort? > > >> > > > >> > > >> Yes it is a loop. I think what you are missing is that it only loops > > >> repeatedly if the driver that aborts suspend does not use a suspend > > >> blocker. > > > > > > You mean "the driver that handles the wakeup event". I was asking what > > > happened if suspend succeeded and then a wakeup occurred. But yes, if > > > a suspend blocker is used then its release causes another suspend > > > attempt, with no looping. > > > > > >> > And even if it isn't, so what? What's wrong with looping behavior? > > >> > > >> It is a significant power drain. > > > > > > Not in the situation I was discussing. > > > > > > > If you meant it spend most of the time suspended, then I agree. It > > only wastes power when a driver blocks suspend by returning an error > > from its suspend hook and we are forced to loop doing no useful work. > > > > If driver refuses to suspend that means there are events that need > processing. I fail to see why it would be called "looping doing no > useful work". I guess Arve meant the case of events that didn't propagate to user space. Rafael > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 27 May 2010 19:40 2010/5/27 Dmitry Torokhov <dmitry.torokhov(a)gmail.com>: > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hj�nnev�g wrote: >> 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: >> > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: >> > >> >> > I must be missing something. �In Arve's patch 1/8, if the system is in >> >> > opportunistic suspend, and a wakeup event occurs but no suspend >> >> > blockers get enabled by the handler, what causes the system to go back >> >> > into suspend after the event is handled? �Isn't that a loop of some >> >> > sort? >> >> > >> >> >> >> Yes it is a loop. I think what you are missing is that it only loops >> >> repeatedly if the driver that aborts suspend does not use a suspend >> >> blocker. >> > >> > You mean "the driver that handles the wakeup event". �I was asking what >> > happened if suspend succeeded and then a wakeup occurred. �But yes, if >> > a suspend blocker is used then its release causes another suspend >> > attempt, with no looping. >> > >> >> > And even if it isn't, so what? �What's wrong with looping behavior? >> >> >> >> It is a significant power drain. >> > >> > Not in the situation I was discussing. >> > >> >> If you meant it spend most of the time suspended, then I agree. It >> only wastes power when a driver blocks suspend by returning an error >> from its suspend hook and we are forced to loop doing no useful work. >> > > If driver refuses to suspend that means there are events that need > processing. I fail to see why it would be called "looping doing no > useful work". Because the useful work is done in another thread. All the loop does is check if the useful work has completed which most likely will slow down the useful work. Blocking suspend with a suspend blocker until the useful work is done is more efficient. -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 27 May 2010 19:50 On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hj�nnev�g wrote: > 2010/5/27 Dmitry Torokhov <dmitry.torokhov(a)gmail.com>: > > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hj�nnev�g wrote: > >> 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: > >> > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > >> > > >> >> > I must be missing something. �In Arve's patch 1/8, if the system is in > >> >> > opportunistic suspend, and a wakeup event occurs but no suspend > >> >> > blockers get enabled by the handler, what causes the system to go back > >> >> > into suspend after the event is handled? �Isn't that a loop of some > >> >> > sort? > >> >> > > >> >> > >> >> Yes it is a loop. I think what you are missing is that it only loops > >> >> repeatedly if the driver that aborts suspend does not use a suspend > >> >> blocker. > >> > > >> > You mean "the driver that handles the wakeup event". �I was asking what > >> > happened if suspend succeeded and then a wakeup occurred. �But yes, if > >> > a suspend blocker is used then its release causes another suspend > >> > attempt, with no looping. > >> > > >> >> > And even if it isn't, so what? �What's wrong with looping behavior? > >> >> > >> >> It is a significant power drain. > >> > > >> > Not in the situation I was discussing. > >> > > >> > >> If you meant it spend most of the time suspended, then I agree. It > >> only wastes power when a driver blocks suspend by returning an error > >> from its suspend hook and we are forced to loop doing no useful work. > >> > > > > If driver refuses to suspend that means there are events that need > > processing. I fail to see why it would be called "looping doing no > > useful work". > > Because the useful work is done in another thread. All the loop does > is check if the useful work has completed which most likely will slow > down the useful work. Or useful work could signal when it is done processing critical section. > Blocking suspend with a suspend blocker until > the useful work is done is more efficient. > -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 27 May 2010 20:00
2010/5/27 Dmitry Torokhov <dmitry.torokhov(a)gmail.com>: > On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hj�nnev�g wrote: >> 2010/5/27 Dmitry Torokhov <dmitry.torokhov(a)gmail.com>: >> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hj�nnev�g wrote: >> >> 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: >> >> > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: >> >> > >> >> >> > I must be missing something. �In Arve's patch 1/8, if the system is in >> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend >> >> >> > blockers get enabled by the handler, what causes the system to go back >> >> >> > into suspend after the event is handled? �Isn't that a loop of some >> >> >> > sort? >> >> >> > >> >> >> >> >> >> Yes it is a loop. I think what you are missing is that it only loops >> >> >> repeatedly if the driver that aborts suspend does not use a suspend >> >> >> blocker. >> >> > >> >> > You mean "the driver that handles the wakeup event". �I was asking what >> >> > happened if suspend succeeded and then a wakeup occurred. �But yes, if >> >> > a suspend blocker is used then its release causes another suspend >> >> > attempt, with no looping. >> >> > >> >> >> > And even if it isn't, so what? �What's wrong with looping behavior? >> >> >> >> >> >> It is a significant power drain. >> >> > >> >> > Not in the situation I was discussing. >> >> > >> >> >> >> If you meant it spend most of the time suspended, then I agree. It >> >> only wastes power when a driver blocks suspend by returning an error >> >> from its suspend hook and we are forced to loop doing no useful work. >> >> >> > >> > If driver refuses to suspend that means there are events that need >> > processing. I fail to see why it would be called "looping doing no >> > useful work". >> >> Because the useful work is done in another thread. All the loop does >> is check if the useful work has completed which most likely will slow >> down the useful work. > > Or useful work could signal when it is done processing critical section. > That is what suspend_unblock does. >> Blocking suspend with a suspend blocker until >> the useful work is done is more efficient. >> > > -- > Dmitry > -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |