[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Paul Mundt on 3 Jun 2010 00:30 On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > And to answer Thomas's question: The whole reason for having in-kernel > > suspend blockers is so that userspace can tell the system to suspend > > without losing wakeup events. > > > > Suppose a key is pressed just as a user program writes "mem" to > > /sys/power/state. The keyboard driver handles the keystroke and queues > > an input event. Then the system suspends and doesn't wake up until > > some other event occurs -- even though the keypress was an important > > one and it should have prevented the system from suspending. > > > > With in-kernel suspend blockers and opportunistic suspend, this > > scenario is prevented. That is their raison-d'etre. > > I tend to disagree. You are still looking at suspend as some extra > esoteric mechanism. We should stop doing this and look at suspend (to > RAM) as an additional deep idle state, which is well defined in terms > of power savings and wakeup latency. That's what I think opportunistic > suspend is all about. Now if you look at our current idle states in > x86 the incoming keystroke is never lost. > For systems with runtime PM and deep idle states in cpuidle suspend is already fairly opportunistic. If sleep states (including suspend to RAM and CPU off) are factored in to cpuidle then it's very easy to get in to situations where everything simply shuts off automatically, which can be problematic if a platform doesn't expose any external wakeup sources. Platforms still need to be able to establish some heuristics, whether this is via blocking certain state transitions or simply defining a maximum acceptable suspend depth irrespective of latency (at least we presently don't have a clean interface for preventing entry in to impossible to recover from idle states outside of latency hints via PM QoS, or at least not one that I'm aware of). On the other hand, while this isn't that difficult for the UP case it does pose more problems for the SMP case. Presently the suspend paths (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and enabling of non-boot CPUs via CPU hotplug explicitly, which will clear them from the online CPU map. We would have to rework the semantics a bit if cpuidle were also permitted to opportunistically offline CPUs. -- 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: Brian Swetland on 3 Jun 2010 01:00 On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920(a)gmail.com> wrote: > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote: >> >> The list is not short. You have all the inactive and active >> constraints on the same list. If you change it to a two level list >> though, the list of unique values (which is the list you have to walk) >> may be short enough for a tree to be overkill. > > what have you seen in practice from the wake-lock stats? > > I'm having a hard time seeing where you could get more than just a > handfull. However; one could go to a dual list (like the scheduler) and > move inactive nodes from an active to inactive list, or we could simply > remove them from the list uppon inactivity. which would would well > after I change the api to have the client allocate the memory for the > nodes... BUT, if your moving things in and out of a list a lot, I'm not > sure the break even point where changing the structure helps. > > We'll need to try it. > > I think we will almost never see more than 10 list elements. > > --mgross > > I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo): Kernel Wake lock "event5-86": (nothing executed) Kernel Wake lock "PowerManagerService": 4m 27s 994ms (453 times) realtime Kernel Wake lock "event4-92": 72ms (10 times) realtime Kernel Wake lock "AudioHardwareQSDIn": (nothing executed) Kernel Wake lock "event4-87": (nothing executed) Kernel Wake lock "event5-82": (nothing executed) Kernel Wake lock "event2-87": (nothing executed) Kernel Wake lock "alarm_rtc": 21s 882ms (186 times) realtime Kernel Wake lock "vdec_suspend": (nothing executed) Kernel Wake lock "event6-87": (nothing executed) Kernel Wake lock "event0-91": (nothing executed) Kernel Wake lock "SMD_DS": 30s 938ms (53 times) realtime Kernel Wake lock "event6-91": (nothing executed) Kernel Wake lock "KeyEvents": 398ms (3226 times) realtime Kernel Wake lock "qmi1": (nothing executed) Kernel Wake lock "mmc_delayed_work": (nothing executed) Kernel Wake lock "event3-82": (nothing executed) Kernel Wake lock "event3-92": 58ms (6 times) realtime Kernel Wake lock "SMD_RPCCALL": 295ms (1756 times) realtime Kernel Wake lock "SMD_DATA6": (nothing executed) Kernel Wake lock "audio_pcm_idle": 3s 99ms (1 times) realtime Kernel Wake lock "serial-debug": (nothing executed) Kernel Wake lock "event6-82": (nothing executed) Kernel Wake lock "event3-86": (nothing executed) Kernel Wake lock "event2-82": (nothing executed) Kernel Wake lock "i2c": (nothing executed) Kernel Wake lock "event2-86": (nothing executed) Kernel Wake lock "event5-87": (nothing executed) Kernel Wake lock "event4-86": (nothing executed) Kernel Wake lock "event5-92": 4ms (21 times) realtime Kernel Wake lock "rpc_server": (nothing executed) Kernel Wake lock "power-supply": 527ms (8 times) realtime Kernel Wake lock "radio-interface": 10s 11ms (10 times) realtime Kernel Wake lock "event6-86": (nothing executed) Kernel Wake lock "deleted_wake_locks": 203ms (214 times) realtime Kernel Wake lock "qmi0": (nothing executed) Kernel Wake lock "event2-91": (nothing executed) Kernel Wake lock "event4-82": (nothing executed) Kernel Wake lock "event7-82": (nothing executed) Kernel Wake lock "dock": 27ms (1 times) realtime Kernel Wake lock "SMD_DATA5": 1m 45s 121ms (158 times) realtime Kernel Wake lock "event1-92": (nothing executed) Kernel Wake lock "gpio_kp": (nothing executed) Kernel Wake lock "event3-87": (nothing executed) Kernel Wake lock "event7-92": (nothing executed) Kernel Wake lock "msm_serial_hs_dma": (nothing executed) Kernel Wake lock "event5-91": (nothing executed) Kernel Wake lock "vbus_present": 517ms (1 times) realtime Kernel Wake lock "alarm": 3s 229ms (249 times) realtime Kernel Wake lock "event1-82": (nothing executed) Kernel Wake lock "venc_suspend": (nothing executed) Kernel Wake lock "event1-86": (nothing executed) Kernel Wake lock "AudioHardwareQSDOut": 3s 98ms (1 times) realtime Kernel Wake lock "event0-87": (nothing executed) Kernel Wake lock "event2-92": 169ms (687 times) realtime Kernel Wake lock "ds2784-battery": 12s 846ms (158 times) realtime Kernel Wake lock "ApmCommandThread": 564ms (2 times) realtime Kernel Wake lock "msmfb_idle_lock": 1s 495ms (715 times) realtime Kernel Wake lock "headset": (nothing executed) Kernel Wake lock "kgsl": 26s 473ms (123 times) realtime Kernel Wake lock "venc_idle": (nothing executed) Kernel Wake lock "event1-91": (nothing executed) Kernel Wake lock "s5k3e2fx": (nothing executed) Kernel Wake lock "usb_mass_storage": (nothing executed) Kernel Wake lock "unknown_wakeups": (nothing executed) Kernel Wake lock "vdec_idle": (nothing executed) Kernel Wake lock "audio_pcm_suspend": 3s 99ms (1 times) realtime Kernel Wake lock "microp_i2c_present": (nothing executed) Kernel Wake lock "event4-91": (nothing executed) Kernel Wake lock "event6-92": 182ms (86 times) realtime Kernel Wake lock "event0-82": (nothing executed) Kernel Wake lock "event0-92": 8ms (37 times) realtime Kernel Wake lock "rpc_read": 112ms (1540 times) realtime Kernel Wake lock "event0-86": (nothing executed) Kernel Wake lock "msm_serial_hs_rx": (nothing executed) Kernel Wake lock "qmi2": (nothing executed) Kernel Wake lock "event1-87": (nothing executed) Kernel Wake lock "msm_camera": (nothing executed) Kernel Wake lock "rpc-interface": 2ms (1 times) realtime Kernel Wake lock "main": 1m 38s 314ms (5 times) realtime Kernel Wake lock "gpio_input": (nothing executed) Kernel Wake lock "event3-91": (nothing executed) Kernel Wake lock "SMD_DATA7": (nothing executed) -- 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: mark gross on 3 Jun 2010 01:50 On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote: > On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920(a)gmail.com> wrote: > > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hj�nnev�g wrote: > >> > >> The list is not short. You have all the inactive and active > >> constraints on the same list. If you change it to a two level list > >> though, the list of unique values (which is the list you have to walk) > >> may be short enough for a tree to be overkill. > > > > what have you seen in practice from the wake-lock stats? > > > > I'm having a hard time seeing where you could get more than just a > > handfull. �However; one could go to a dual list (like the scheduler) and > > move inactive nodes from an active to inactive list, or we could simply > > remove them from the list uppon inactivity. �which would would well > > after I change the api to have the client allocate the memory for the > > nodes... �BUT, if your moving things in and out of a list a lot, I'm not > > sure the break even point where changing the structure helps. > > > > We'll need to try it. > > > > I think we will almost never see more than 10 list elements. > > > > --mgross > > > > > > I see about 80 (based on the batteryinfo dump) on my Nexus One > (QSD8250, Android Froyo): shucks. well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats. > Kernel Wake lock "event5-86": (nothing executed) > Kernel Wake lock "PowerManagerService": 4m 27s 994ms (453 times) realtime > Kernel Wake lock "event4-92": 72ms (10 times) realtime > Kernel Wake lock "AudioHardwareQSDIn": (nothing executed) > Kernel Wake lock "event4-87": (nothing executed) > Kernel Wake lock "event5-82": (nothing executed) > Kernel Wake lock "event2-87": (nothing executed) > Kernel Wake lock "alarm_rtc": 21s 882ms (186 times) realtime > Kernel Wake lock "vdec_suspend": (nothing executed) > Kernel Wake lock "event6-87": (nothing executed) > Kernel Wake lock "event0-91": (nothing executed) > Kernel Wake lock "SMD_DS": 30s 938ms (53 times) realtime > Kernel Wake lock "event6-91": (nothing executed) > Kernel Wake lock "KeyEvents": 398ms (3226 times) realtime > Kernel Wake lock "qmi1": (nothing executed) > Kernel Wake lock "mmc_delayed_work": (nothing executed) > Kernel Wake lock "event3-82": (nothing executed) > Kernel Wake lock "event3-92": 58ms (6 times) realtime > Kernel Wake lock "SMD_RPCCALL": 295ms (1756 times) realtime > Kernel Wake lock "SMD_DATA6": (nothing executed) > Kernel Wake lock "audio_pcm_idle": 3s 99ms (1 times) realtime > Kernel Wake lock "serial-debug": (nothing executed) > Kernel Wake lock "event6-82": (nothing executed) > Kernel Wake lock "event3-86": (nothing executed) > Kernel Wake lock "event2-82": (nothing executed) > Kernel Wake lock "i2c": (nothing executed) > Kernel Wake lock "event2-86": (nothing executed) > Kernel Wake lock "event5-87": (nothing executed) > Kernel Wake lock "event4-86": (nothing executed) > Kernel Wake lock "event5-92": 4ms (21 times) realtime > Kernel Wake lock "rpc_server": (nothing executed) > Kernel Wake lock "power-supply": 527ms (8 times) realtime > Kernel Wake lock "radio-interface": 10s 11ms (10 times) realtime > Kernel Wake lock "event6-86": (nothing executed) > Kernel Wake lock "deleted_wake_locks": 203ms (214 times) realtime > Kernel Wake lock "qmi0": (nothing executed) > Kernel Wake lock "event2-91": (nothing executed) > Kernel Wake lock "event4-82": (nothing executed) > Kernel Wake lock "event7-82": (nothing executed) > Kernel Wake lock "dock": 27ms (1 times) realtime > Kernel Wake lock "SMD_DATA5": 1m 45s 121ms (158 times) realtime > Kernel Wake lock "event1-92": (nothing executed) > Kernel Wake lock "gpio_kp": (nothing executed) > Kernel Wake lock "event3-87": (nothing executed) > Kernel Wake lock "event7-92": (nothing executed) > Kernel Wake lock "msm_serial_hs_dma": (nothing executed) > Kernel Wake lock "event5-91": (nothing executed) > Kernel Wake lock "vbus_present": 517ms (1 times) realtime > Kernel Wake lock "alarm": 3s 229ms (249 times) realtime > Kernel Wake lock "event1-82": (nothing executed) > Kernel Wake lock "venc_suspend": (nothing executed) > Kernel Wake lock "event1-86": (nothing executed) > Kernel Wake lock "AudioHardwareQSDOut": 3s 98ms (1 times) realtime > Kernel Wake lock "event0-87": (nothing executed) > Kernel Wake lock "event2-92": 169ms (687 times) realtime > Kernel Wake lock "ds2784-battery": 12s 846ms (158 times) realtime > Kernel Wake lock "ApmCommandThread": 564ms (2 times) realtime > Kernel Wake lock "msmfb_idle_lock": 1s 495ms (715 times) realtime > Kernel Wake lock "headset": (nothing executed) > Kernel Wake lock "kgsl": 26s 473ms (123 times) realtime > Kernel Wake lock "venc_idle": (nothing executed) > Kernel Wake lock "event1-91": (nothing executed) > Kernel Wake lock "s5k3e2fx": (nothing executed) > Kernel Wake lock "usb_mass_storage": (nothing executed) > Kernel Wake lock "unknown_wakeups": (nothing executed) > Kernel Wake lock "vdec_idle": (nothing executed) > Kernel Wake lock "audio_pcm_suspend": 3s 99ms (1 times) realtime > Kernel Wake lock "microp_i2c_present": (nothing executed) > Kernel Wake lock "event4-91": (nothing executed) > Kernel Wake lock "event6-92": 182ms (86 times) realtime > Kernel Wake lock "event0-82": (nothing executed) > Kernel Wake lock "event0-92": 8ms (37 times) realtime > Kernel Wake lock "rpc_read": 112ms (1540 times) realtime > Kernel Wake lock "event0-86": (nothing executed) > Kernel Wake lock "msm_serial_hs_rx": (nothing executed) > Kernel Wake lock "qmi2": (nothing executed) > Kernel Wake lock "event1-87": (nothing executed) > Kernel Wake lock "msm_camera": (nothing executed) > Kernel Wake lock "rpc-interface": 2ms (1 times) realtime > Kernel Wake lock "main": 1m 38s 314ms (5 times) realtime > Kernel Wake lock "gpio_input": (nothing executed) > Kernel Wake lock "event3-91": (nothing executed) > Kernel Wake lock "SMD_DATA7": (nothing executed) How much of this is portable to your next phone? I bet it was a big effort to get these right too. FWIW I don't think most of these will map into the moorestown port of android I'm working on. This is why I really think a low power event framework would be cleaner but, lets make everyone happy and expand pm_qos into a wake lock re-implementation first. --mgross -- 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: Brian Swetland on 3 Jun 2010 03:00 On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt <lethal(a)linux-sh.org> wrote: > > On the other hand, while this isn't that difficult for the UP case it > does pose more problems for the SMP case. Presently the suspend paths > (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and > enabling of non-boot CPUs via CPU hotplug explicitly, which will clear > them from the online CPU map. We would have to rework the semantics a bit > if cpuidle were also permitted to opportunistically offline CPUs. That's definitely something we'd be interested in looking at. Some upcoming ARM v7 architecture SMP SoCs we're seeing will support full independent clock scaling and power gating for the individual cores -- if there's not enough work to keep the 2nd (or nth) cpu busy, there would be good power savings to be had shutting it down. I haven't poked around too much with how things work in SMP environments -- are there per-cpu idle threads? Brian -- 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 3 Jun 2010 03:20
On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920(a)gmail.com> wrote: > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote: >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920(a)gmail.com> wrote: >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hj�nnev�g wrote: >> >> >> >> The list is not short. You have all the inactive and active >> >> constraints on the same list. If you change it to a two level list >> >> though, the list of unique values (which is the list you have to walk) >> >> may be short enough for a tree to be overkill. >> > >> > what have you seen in practice from the wake-lock stats? >> > >> > I'm having a hard time seeing where you could get more than just a >> > handfull. �However; one could go to a dual list (like the scheduler) and >> > move inactive nodes from an active to inactive list, or we could simply >> > remove them from the list uppon inactivity. �which would would well >> > after I change the api to have the client allocate the memory for the >> > nodes... �BUT, if your moving things in and out of a list a lot, I'm not >> > sure the break even point where changing the structure helps. >> > >> > We'll need to try it. >> > >> > I think we will almost never see more than 10 list elements. >> > >> > --mgross >> > >> > >> >> I see about 80 (based on the batteryinfo dump) on my Nexus One >> (QSD8250, Android Froyo): > > shucks. > > well I think for a pm_qos class that has boolean dynamic range we can > get away with not walking the list on every request update. �we can use > a counter, and the list will be for mostly for stats. > Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have. A request update then becomes something like this: if on primary list { unlink from primary list if secondary list is not empty get next secondary entry and add in same spot on primary list } unlink from secondary list find new spot on primary list if already there add to secondary list else add to primary list -- 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/ |