2010/5/26 Peter Zijlstra <peterz@xxxxxxxxxxxxx>: > 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. x86 systems already auto-suspend. > > 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. > Why? If your suspend is currently set to sleep after 30 minutes of inactivity, you can still have the same setting with opportunistic suspend. With opportunistic suspend you can have an alarm set to run a task at a specific time without risking that this task does not run at that time just because your inactivity timer expired at the same time as the alarm went off. > 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 me this is not a good argument for not merging the code. If people stop caring about the problem if this feature is merged that means it solved a problem for them. You want to prevent merging a feature _because_ it solves a problem. -- Arve Hjønnevåg -- 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
