Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/