On Mon, 2010-05-17 at 22:35 +0100, Matthew Garrett wrote: > On Mon, May 17, 2010 at 02:29:24PM -0700, Daniel Walker wrote: > > On Mon, 2010-05-17 at 22:24 +0100, Matthew Garrett wrote: > > > > I was more thinking about something new, that isn't freezing anything. > > > > The only purpose would be to group the stuff that CPUidle can ignore, > > > > and let CPUidle ignore it, so that the system can still be idled. > > > > > > So they'd be on the runqeue but wouldn't factor into cpuidle's > > > calculations of when the next wakeup should be? Ok. I think that still > > > leaves you with the same problem - you're not scheduling that task, so > > > how do you know to execute it when a network packet is received? I think > > > you also still have the race condition. > > > > Couldn't you special case the network packet situation ? Like the idle > > loop could take into account that there are packets flowing through the > > networking stack that may need to get handled. > > And once you've done that for every wakeup source you have something > that looks pretty much like suspend blockers. Well, maybe (this is theoretical after all), but it's within the confines of our current PM model .. You basically centralize all the decision making into the kernel, and into idle. that seems to me more powerful than suspend blockers since they interleave parts with userspace. Daniel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
