PM: Add suspend block api.
in [Kernel]
|
Prev: A share can be mounted multiple times on the same mountpoint when using the option 'noac'
Next: parport_pc.c and parport_serial.c need improvements
From: Florian Mickler on 20 May 2010 05:20 On Tue, 18 May 2010 15:11:11 +0200 Pavel Machek <pavel(a)ucw.cz> wrote: > On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote: > > Adds /sys/power/policy that selects the behaviour of /sys/power/state. > > After setting the policy to opportunistic, writes to /sys/power/state > > become non-blocking requests that specify which suspend state to > > enter > > Yeah, one file selects behavior of another file, and to read available > states for opportunistic, you have to write to file first. > > I still don't like the interface. > Actually, what would be a better interface? I wonder why it is not like this: /sys/power/state no change, works with and without opportunistic suspend the same. Ignores suspend blockers. Really no change. (From user perspective) /sys/power/opportunistic On / Off While Off the opportunistic suspend is off. While On, the opportunistic suspend is on and if there are no suspend blockers the system goes to suspend. Cheers, Flo -- 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: Florian Mickler on 20 May 2010 05:30 On Thu, 20 May 2010 11:11:11 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Tue, 18 May 2010 15:11:11 +0200 > Pavel Machek <pavel(a)ucw.cz> wrote: > > > On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote: > > > Adds /sys/power/policy that selects the behaviour of /sys/power/state. > > > After setting the policy to opportunistic, writes to /sys/power/state > > > become non-blocking requests that specify which suspend state to > > > enter > > > > Yeah, one file selects behavior of another file, and to read available > > states for opportunistic, you have to write to file first. > > > > I still don't like the interface. > > > > Actually, what would be a better interface? > > I wonder why it is not like this: > > /sys/power/state > no change, works with and without opportunistic suspend the > same. Ignores suspend blockers. Really no change. (From user > perspective) > > /sys/power/opportunistic > On / Off > While Off the opportunistic suspend is off. > While On, the opportunistic suspend is on and if there are no > suspend blockers the system goes to suspend. > I forgot, of course there needs to be another knob to implement the "on" behaviour in the opportunistic mode /sys/power/block_opportunistic_suspend There you have it. One file, one purpose. > Cheers, > Flo -- 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: Rafael J. Wysocki on 20 May 2010 18:20 On Thursday 20 May 2010, Florian Mickler wrote: > On Thu, 20 May 2010 11:11:11 +0200 > Florian Mickler <florian(a)mickler.org> wrote: > > > On Tue, 18 May 2010 15:11:11 +0200 > > Pavel Machek <pavel(a)ucw.cz> wrote: > > > > > On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote: > > > > Adds /sys/power/policy that selects the behaviour of /sys/power/state. > > > > After setting the policy to opportunistic, writes to /sys/power/state > > > > become non-blocking requests that specify which suspend state to > > > > enter > > > > > > Yeah, one file selects behavior of another file, and to read available > > > states for opportunistic, you have to write to file first. > > > > > > I still don't like the interface. > > > > > > > Actually, what would be a better interface? > > > > I wonder why it is not like this: Because I think the "forced" and "opportunistic" suspend "modes" are mutually exclusive in practice and the interface as proposed reflects that quite well. > > /sys/power/state > > no change, works with and without opportunistic suspend the > > same. Ignores suspend blockers. Really no change. (From user > > perspective) > > > > /sys/power/opportunistic > > On / Off > > While Off the opportunistic suspend is off. > > While On, the opportunistic suspend is on and if there are no > > suspend blockers the system goes to suspend. > > > > I forgot, of course there needs to be another knob to implement the > "on" behaviour in the opportunistic mode > > /sys/power/block_opportunistic_suspend > > There you have it. One file, one purpose. That's getting messy IMHO. In addition to that you get a nice race when the user writes "mem" to /sys/power/state and opportunistic suspend happens at the same time. If the latter wins the race, the system will suspend again immediately after being woken up, which probably is not the result you'd like to get. Thanks, 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: Rafael J. Wysocki on 20 May 2010 18:30 On Thursday 20 May 2010, Tejun Heo wrote: > Hello, > > (sorry about late reply) > > On 04/30/2010 07:26 PM, Oleg Nesterov wrote: > > Currently _cpu_down() can't flush and/or stop the frozen cwq->thread. > > > > IIRC this is fixable, but needs the nasty complications. We should > > thaw + stop the frozen cwq->thread, then move the pending works to > > another CPU. > > Oh, this isn't an issue w/ cmwq. While frozen all new works are > collected into per-cpu delayed worklist and while frozen trustee in > charge of the cpu will keep waiting. Once thawed, trustee will > execute all works including the delayed ones unbound to any cpu. So, does it require any intrusive changes to make it possible to create multithread freezable workqueues? 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: Florian Mickler on 21 May 2010 02:30
On Fri, 21 May 2010 00:18:43 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > Actually, what would be a better interface? > > > > > > I wonder why it is not like this: > > Because I think the "forced" and "opportunistic" suspend "modes" are mutually > exclusive in practice and the interface as proposed reflects that quite well. > > > > /sys/power/state > > > no change, works with and without opportunistic suspend the > > > same. Ignores suspend blockers. Really no change. (From user > > > perspective) > > > > > > /sys/power/opportunistic > > > On / Off > > > While Off the opportunistic suspend is off. > > > While On, the opportunistic suspend is on and if there are no > > > suspend blockers the system goes to suspend. > > > > > > > I forgot, of course there needs to be another knob to implement the > > "on" behaviour in the opportunistic mode > > > > /sys/power/block_opportunistic_suspend > > > > There you have it. One file, one purpose. > > That's getting messy IMHO. > > In addition to that you get a nice race when the user writes "mem" > to /sys/power/state and opportunistic suspend happens at the same time. > If the latter wins the race, the system will suspend again immediately after > being woken up, which probably is not the result you'd like to get. But I don't think there is a problem with that. If the system is 'awake' (suspend blocked) and you hit it with forced 'mem', the system _has_ to suspend. as that is what forced "mem" means. And if opportunistic won the race you would _expect_ the machine to suspend again after the wakeup (and this time for good). But perhaps this only makes sense if you can specify different wake-events for opportunistic and forced suspend. This is probably some kind of bikeshed by now. I'm alright with the status quo. For what it's worth (not much): You can add my Reviewed-By. Cheers, Flo -- 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/ |