Re: inhibiting suspend via dbus
Deepak Saxena wrote: On Aug 09 2008, at 19:35, Mikus Grinbergs was caught saying: One possibility -- OFW already tests for is the XO plugged in?. Maybe Ohm can test for that, and decide that suspend is not needed when the battery is fully charged, and is not being drained. I don't think this would work for us as in some locations electrical power is expensive and we want to conserve as much power as possible. This was indeed the way ohm used to work but I argued against it because plugged up to external power in no way indicates you have a constant electrical source. Many cases that will be sharing a connection to a solar panel or from a battery bank and you need to be save as much as possible all the time. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
smith wrote: Deepak Saxena wrote: On Aug 09 2008, at 19:35, Mikus Grinbergs was caught saying: One possibility -- OFW already tests for is the XO plugged in?. Maybe Ohm can test for that, and decide that suspend is not needed when the battery is fully charged, and is not being drained. I don't think this would work for us as in some locations electrical power is expensive and we want to conserve as much power as possible. This was indeed the way ohm used to work but I argued against it because plugged up to external power in no way indicates you have a constant electrical source. Many cases that will be sharing a connection to a solar panel or from a battery bank and you need to be save as much as possible all the time. this could still be selectable. while it's necessary to provide for those scenarios, i suspect that most laptops will have reliable external power. i'd think a don't suspend when plugged in checkbox would be useful for most owners. (it could default to off.) also, mikus' suggestion re: watching the rate of discharge is interesting. i wonder if that might be a useful input to the OHM policy engine? (e.g. decrease timeouts when the rate of discharge is high) just an ill-formed thought. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
On Aug 09 2008, at 19:35, Mikus Grinbergs was caught saying: One possibility -- OFW already tests for is the XO plugged in?. Maybe Ohm can test for that, and decide that suspend is not needed when the battery is fully charged, and is not being drained. I don't think this would work for us as in some locations electrical power is expensive and we want to conserve as much power as possible. It could be made into a user-configurable setting via the control panel for those situations where we do want this behaviour. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
inhibiting suspend via dbus
As it turns out, the activity update control panel needs to inhibit suspend, too, otherwise we go to sleep in the middle of downloading large activities (Firefox, TamTam, etc). Chris, could you make a little wiki page explaining how to interact w/ ohm via dbus to temporarily inhibit suspend, and send me the [[link]]? I figure other people who want to do other long-lived tasks could use this information, too; it should perhaps be included in the activity API docs. (Does Browse properly inhibit suspend during download? It probably should.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
As it turns out, the activity update control panel needs to inhibit suspend, too, otherwise we go to sleep in the middle of downloading large activities (Firefox, TamTam, etc). Chris, could you make a little wiki page explaining how to interact w/ ohm via dbus to temporarily inhibit suspend, and send me the [[link]]? I figure other people who want to do other long-lived tasks could use this information, too; it should perhaps be included in the activity API docs. (Does Browse properly inhibit suspend during download? It probably should.) No, this is the wrong approach. We shouldn't be patching every program to avoid suspending at various times. We should be improving the heuristic that the system (Ohm) uses to decide when to suspend. Once we have better information from the kernel about what the running processes are doing, we'd just have to rip out all the little kludges inserted into every program. Normally, when a TCP connection is active, even a suspended XO should break out of suspend when the next packet arrives from the other end. Only if it happens to suspend in the brief interval between receiving that packet and asking for the next one, will such a suspend persist indefinitely. But there may be bugs there (e.g. #6528). We already have bugs because Read was hacked to force suspends, and it turns out it's suspending at the wrong times (#6645, #6684). Let's not add more bugs by hacking more activities to force or unforce suspends. We should understand why ohm isn't noticing that the activity updater isn't idle. Should Ohm be looking for a higher cpu idle% in the seconds before it suspends? Should it be looking for minimal numbers of context switches per second before it suspends? What does the system look like when the updater is running? If we can confine our suspend-kludge patches to one place (ohm) we'll be much better off in the medium and long term. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
We shouldn't be patching every program to avoid suspending at various times. We should be improving the heuristic that the system (Ohm) uses to decide when to suspend. Once we have better information from the kernel about what the running processes are doing, we'd just have to rip out all the little kludges inserted into every program. Currently no good definition of criteria exists. I've seen two situations where I need 'inhibit-idle-suspend'. My current attitude is -- I'll set that flag manually when I'm doing these things, and will clear that flag when I can again tolerate suspend: (1) While downloading. I use ethernet, and it has been explained to me that this uses *less* CPU than the keep-alive processes for which Ohm makes an allowance. (2) While running a background computation. It has been suggested that I should use a wrapper, which sends notifications to Ohm. But this is someone else's binary, and uses dynamic dispatching of executables. I really really don't want to monkey with it. One possibility -- OFW already tests for is the XO plugged in?. Maybe Ohm can test for that, and decide that suspend is not needed when the battery is fully charged, and is not being drained. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
