On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: > 2010/5/26 Peter Zijlstra <peterz@xxxxxxxxxxxxx>: > > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: > >> 2010/5/26 Peter Zijlstra <peterz@xxxxxxxxxxxxx>: > >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: > >> > > >> >> and on systems where the > >> >> same power state can be used from idle and suspend, we use suspend so > >> >> we can stay in the low power state for minutes to hours instead of > >> >> milliseconds to seconds. > >> > > >> > So don't you think working on making it possible for systems to be idle > >> > _that_ long would improve things for everybody? as opposed to this > >> > auto-suspend which only improves matters for those that (can) use it? > >> > >> I'm not preventing anyone from working on improving this. Currently > >> both the kernel and our user-space code polls way too much. I don't > >> think it is reasonable to demand that no one should run any user-space > >> code with periodic timers when we have not even fixed the kernel to > >> not do this. > > > > All I'm saying is that merging a stop-gap measure will decrease the > > urgency and thus the time spend fixing the actual issues while adding > > the burden of maintaining this stop-gap measure. > > > > Fixing the actually issue means fixing all user-space code, and > replacing most x86 hardware. I don't think keeping this feature out of > the kernel will significantly accelerate this. I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere near fast enough for this to be usable. My laptop still takes several seconds to suspend (Lenovo T500), and resume (aside from some userspace bustage) takes the same amount of time. That is quick enough for manual suspend, but I'd hate it to try and auto-suspend. Getting longer idle periods however is something that everybody benefits from. On x86 we're nowhere close to hitting the max idle time of the platform, you get _tons_ of wakeups on current 'desktop' software. But x86 being a PITA shouldn't stop people from working on this, there's plenty other architectures out there, I remember fixing a NO_HZ bug with davem on sparc64 because his niagra had cores idling for very long times indeed. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
