Idle-suspend a little too intrusive to user experience?

[John Gilmore]

> > just fix the kernel so the suspend
> > ends when the next process wants to run.
> 
> Have a look at powertop -- you'll never suspend, there are several
> hundred wakeups per second.

Did we give up on fixing these?

(I don't have an XO-1.5 so I can't see its powertop results.)

> If you want to do better than super-idling the way that recent kernels
> do, you have to get into the "suspend transparently and aggressively"
> game, like modern mobile phones do.

I don't think I want my computers to become as stupid as my phones.

Programs don't have to busy-wait.  We defined kernel interfaces for
programs to wait for things to happen, decades ago.  We've evolved
them as needed.  When a clueless program maxes out the CPU by
busy-waiting, historically it gets patched or fixed so that it does a
kernel call that makes it sleep when there's nothing to do -- and lets
the kernel know what event should wake it up.

As far as I can tell, that paradigm has not failed us.  We just need
to move from fixing the programs that burn 100% of the CPU when idle,
to fixing the programs that wake up dozens of times a second when
idle.  Replacing that with a new model of "transparent and aggressive"
suspends (that are not transparent to user programs) is a problem, not
a solution.

I detected a wakeup bug in the Python interpreter three years ago.
After some nudging, Guido made a Python interpreter patch, letting
signals be transmitted via a file descriptor, preventing it from doing
10 useless wakeups/sec in case a signal might have arrived.  Then the
libraries needed to be patched to use the new interface.  The whole
integrated fix is *still* not in production, as far as I can tell:

  Sugar apps' pygtk main loop polls 10 times a second, always
  http://dev.laptop.org/ticket/4680

  Patch for signal.set_wakeup_fd
  http://bugs.python.org/issue1583

  python-2.5.2-set_wakeup_fd4.patch is not what went upstream
  https://bugzilla.redhat.com/show_bug.cgi?id=475005

  Calling gobject.threads_init() causes a lot of wakeups (PyGObject)
  https://bugzilla.gnome.org/show_bug.cgi?id=481569

  Calling gobject.threads_init() causes a lot of wakeups (PyGTK)
  https://bugzilla.gnome.org/show_bug.cgi?id=611050

Perhaps these fixes have made it into F12?  Are all our multitasked
Python programs waking up 10x/sec now, or not?  If they are still
waking up 10x per second, let's fix this bug.  (If it's fixed, let's
close those tickets.)  Let's not introduce some new API so the kernel
can tell the difference between when they really *mean* to wake up,
versus when they are just waking up because they don't know any
better.

> It is a pain -- some cases can be handled transparently, others need a
> bit of work in making the apps suspend-aware. But the payoff is huge.

The huge payoff you mention is that you can brute-force "aggressive
suspend with numerous bugs" into a product and improve one release of
one product's battery life.  But portable apps won't run well on your
product, because there's no real reason for your extra API.  And
you'll have bugs from Day 1 to Kingdom Come, because you broke the
cleanly defined interface between the kernel and the user programs.
(This set of bugs is why we never shipped with aggressive suspend
enabled on the XO-1.  Let me guess, the now-smaller XO software support
org has decided it can live with this level of bugs, so has reversed
that decision.  Now "the XO-1.5 uses less power than the XO-1", but
of course the XO-1 would use less power if you turned on "agressive
and intrusive" suspends there too.)

A cleanly defined kernel interface doesn't require "making apps
suspend-aware".  Aggressive suspend is just doing it clumsily
because we had no time to do it right.

	John