On Friday 28 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote: > > What happens if the user presses the button right before you set QoS > > of 'user apps' to QS_NONE? > > To me it looks like this solution would result in this sequence which > > may ignore the button press: > > Button pushed > > Button driver sets QoS of app it wakes to QS_ABOVESUSPEND > > Set QoS of 'user apps' to QS_NONE > > I don't think we should change app QoS parameters, but change service > provider parameters. > > For instance, suppose the filesystem-IO QoS has 3 levels: > High, Normal and Idle. > > Then if we assign Idle to updatedb, we'll service it as long as the > filesystem-server QoS has a higher level (High and Normal). When we > change the filesystem-serves' QoS to idle, it finds there is nothing to > keep it servicing stuff and it'll block pending requests, updatedb stops > being runnable and we're good. Yeah, that's what I was thinking. It would be nice to have a mechanism that would prevent tasks from being runnable in specific conditions (not necessarily related to power management even). Having reconsidered the suspend blockers idea I came to the conclusion that in fact it was a workaround for three different problems. The first one was that we couldn't power manage I/O devices at run time and the only way to put them into low-power states was to carry out full system suspend. That's changed with the introduction of the runtime PM framework, but the situation is still not ideal, because in general there's no connection between the idle infrastructure and runtime PM. This IMO is the second problem worked around by suspend blockers. Namely, it generally would be nice to suspend I/O devices when CPUs are idle for a sufficiently long time. For this to work, there should be a way to register a device with the idle framework so that it can tell the device's driver to suspend the device when it makes sense. Something like <vague idea>idle_register_device(dev, t), where t means "suspend that device after all CPUs have been idle for time t", so basically the idle framework will only need to run pm_schedule_suspend(dev, t) for that device right before idling the last CPU</vague idea>. The third problem is exactly that on Android system there are (or at least there may be) tasks that in specific situations should not be regarded as runnable at all and currently there's no way to ensure they won't run other than going to a full suspend. If we could address these issues somehow, I think suspend blockers would not be necessary for maximizing battery life (well, there are some technical details like automatic going to full suspend when the CPUs and I/O have been idle for sufficiently long etc., but they all seem to be tractable). [And there's a problem of periodic timers that trigger too often, but I think that's just a general issue that need to be fixed anyway.] Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
