From: Ted Ts'o on
On Sun, Aug 08, 2010 at 08:40:28PM +0300, Felipe Contreras wrote:
>
> My guess is you haven't used a truly multi-tasking device like the
> N900; now that I've got used to it, I consider that functionality
> *essential*.

I've used an N800, and I wasn't impressed; if anything, the fact that
I have to worry about manually killing off applications when memory
gets low, I actually thought it was incredibly sucky. It was a
miniature, badly done laptop.

Maybe the N900 is different, but the bigger question is what do you
mean by "multi-tasking"? Definitions are critical here, which is why
Paul was so careful in his definitions section of his document.

Do you mean:

* allowing multiple processes running at the same time?
* allowing some applications to be able to update mail, play audio,
upload location information so your friends know where you are?
* allowing arbitrary applications that users can interact with
simultaneously (which implies a window manager, the need to have
the concept of window focus for keyboard input), etc?

or something else?

> The argument in favor of suspend blockers is that you could take
> applications that are not designed for embedded, and make them run on
> an embedded device without draining excessive battery life; those
> applications would have to be background services not conflicting with
> Android's design.
>
> I agree there probably would not be that many background apps, and
> probably even less ported background apps, but that is actually an
> argument against suspend blockers.
>
> The rest of the apps (UI apps), cannot be ported, but have to be
> written specifically for Android, and therefore should have PM in
> mind, and not require suspend blockers to have good power usage.

If you are using a GUI framework which is optimized for a single-
application-focus-at-a-time UI that isn't GNOME or KDE, then that will
require the applications to be written. However, that's not because
of suspend-blockers.

If you assume a GUI framework which is flexible enough --- maybe Qt
falls into this category, maybe not --- for the rest of the
applications, they don't need to *know* about suspend blockers, and
they certainly do't have to be rewritten or modified specifically for
suspend blockers. So if your argument is that applications that don't
need bacground services (which you've admitted comprises majority of
applicatios) need to be modified or written specifically to support
suspend blockers, that's simply not true. They don't need to be
modified at all.

As far as whether they *should* require suspend blockers to be in the
kernel to get power usage that is suitable for cell phone batteries, I
would agree that in the ideal world, it would be nice if you could
have applications that make the correct performance/battery
utilization tradeoff for devices running on 800 mWh batteries, 94,000
mWh batteries, and while running on the AC mains. But I don't believe
that it's likely to be true, and if you want to try to beat up on
application writers one at a time to be power optimized --- as far as
I'm concerned, that's an argument *for* suspend blockers, since I'm
not big believer in plans that begin, "First, you command the tides of
the sea to go back", King Canute style. :-)

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> I have to worry about manually killing off applications when memory
> gets low, I actually thought it was incredibly sucky. It was a
> miniature, badly done laptop.

Likewise I thought the lack of proper multi-tasking apps in Android was
comically bad. Nice device completely wrecked by the inability to flip
between running apps each with their own screen - something that was old
tech in 1990.

It's no use looking at this from an "In my opinion" angle. A proper
solution works for most if not all opinions except maybe around corner
cases.

> * allowing arbitrary applications that users can interact with
> simultaneously (which implies a window manager, the need to have
> the concept of window focus for keyboard input), etc?

That's also untrue as anyone who has worked in industrial control or
entertainment systems will tell you. You may well have fourteen apps
driving fourteen display/input devices and no window manager.

> would agree that in the ideal world, it would be nice if you could
> have applications that make the correct performance/battery
> utilization tradeoff for devices running on 800 mWh batteries, 94,000
> mWh batteries, and while running on the AC mains. But I don't believe
> that it's likely to be true, and if you want to try to beat up on
> application writers one at a time to be power optimized --- as far as
> I'm concerned, that's an argument *for* suspend blockers, since I'm
> not big believer in plans that begin, "First, you command the tides of
> the sea to go back", King Canute style. :-)

Suspend blockers drive the system policy part way into the apps, that in
turn makes the apps very vulnerable to change in their environment because
you've specialised them. I am sure that in the Android world it's
considered fine, and that the marketing and business people even like
this binding together - but it doesn't generalise and will blow up in
people's faces in the future.

To consider your tide analogy - suspend blockers is like trying to
program the waves individually. Show me a suspend blocker aware open
office patch 8)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:

[ . . . ]

> > would agree that in the ideal world, it would be nice if you could
> > have applications that make the correct performance/battery
> > utilization tradeoff for devices running on 800 mWh batteries, 94,000
> > mWh batteries, and while running on the AC mains. But I don't believe
> > that it's likely to be true, and if you want to try to beat up on
> > application writers one at a time to be power optimized --- as far as
> > I'm concerned, that's an argument *for* suspend blockers, since I'm
> > not big believer in plans that begin, "First, you command the tides of
> > the sea to go back", King Canute style. :-)
>
> Suspend blockers drive the system policy part way into the apps, that in
> turn makes the apps very vulnerable to change in their environment because
> you've specialised them. I am sure that in the Android world it's
> considered fine, and that the marketing and business people even like
> this binding together - but it doesn't generalise and will blow up in
> people's faces in the future.
>
> To consider your tide analogy - suspend blockers is like trying to
> program the waves individually. Show me a suspend blocker aware open
> office patch 8)

But wouldn't an office suite run as a power-oblivious application on an
Android device? After all, office applications do not need to run when
the screen is turned off, so these the applications do not need to use
suspend blockers. That said, I could easily imagine that significant
work would be required to make OpenOffice run on Android, not due to
suspend blockers, but rather due to Android's unusual user space.

On devices that do not have suspend blockers, a normal application runs
in a manner similar to a hypothetical Android application that acquires
a suspend blocker when it starts and holds that suspend blocker until
it exits. In contrast with Android, this situation requires that each
and every application be carefully written to avoid battery drain,
which I suspect is what Ted is getting at with his King Canute analogy.

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: david on
On Mon, 9 Aug 2010, Paul E. McKenney wrote:

> On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
>
> [ . . . ]
>
>>> would agree that in the ideal world, it would be nice if you could
>>> have applications that make the correct performance/battery
>>> utilization tradeoff for devices running on 800 mWh batteries, 94,000
>>> mWh batteries, and while running on the AC mains. But I don't believe
>>> that it's likely to be true, and if you want to try to beat up on
>>> application writers one at a time to be power optimized --- as far as
>>> I'm concerned, that's an argument *for* suspend blockers, since I'm
>>> not big believer in plans that begin, "First, you command the tides of
>>> the sea to go back", King Canute style. :-)
>>
>> Suspend blockers drive the system policy part way into the apps, that in
>> turn makes the apps very vulnerable to change in their environment because
>> you've specialised them. I am sure that in the Android world it's
>> considered fine, and that the marketing and business people even like
>> this binding together - but it doesn't generalise and will blow up in
>> people's faces in the future.
>>
>> To consider your tide analogy - suspend blockers is like trying to
>> program the waves individually. Show me a suspend blocker aware open
>> office patch 8)
>
> But wouldn't an office suite run as a power-oblivious application on an
> Android device? After all, office applications do not need to run when
> the screen is turned off, so these the applications do not need to use
> suspend blockers. That said, I could easily imagine that significant
> work would be required to make OpenOffice run on Android, not due to
> suspend blockers, but rather due to Android's unusual user space.

pick your application if you don't like the example.

but also, which android system should the applicaton be written for? the
phone with a 800maH battery or a larger device with a 94,000maH battery?

well bahaved applications (not doing unnecessary wakeups, etc) are well
bahaved, no matter what system they are on (explicitly setting allowable
timer fuzz is linux specific, but will again help on any system)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> But wouldn't an office suite run as a power-oblivious application on an
> Android device? After all, office applications do not need to run when

I was waiting for soemone to leap down the pit I dug Office suites have
some quite important background activities. Consider the case of a power
oblivious Open Office. You type a critical document, you suspend, your
phone battery dies a bit later, you lost your document. Office suites do
timed backing up as one simple obvious example. That could become a power
aware behaviour but the truely power oblivious office suite is a myth.

> the screen is turned off, so these the applications do not need to use
> suspend blockers. That said, I could easily imagine that significant
> work would be required to make OpenOffice run on Android, not due to
> suspend blockers, but rather due to Android's unusual user space.

You are tightly linking suspend blockers with Android. If they were a
sensible general solution they would be generic not tied closely to
Android

Some of the other bad assumptions being made in this discussion:

- That the phone is special. Todays Android phones are up with the PC's
of some years back (but with better graphics and more faster storage),
in a few more generations of the technology what will they look like ?
I'm sure that within a few years there will be people playing Warcraft
or similar on their phone in the train.

- That Android will continue to tbe offering the same services in future
as today. If it does it'll go the way of PalmOS and Symbian. Equally
you can't just bust all the apps as it changes

As devices get more complex and varied you cannot afford to put the
detailed awareness of platform behaviour in the applications. It
doesn't scale. Android developers are haivng enough fun coping with all
the OS variants, customisations and new phones - and thats far less
variety than PC hardware. Generally the PC app folks are not having the
same level of problem - so ask why ?

> On devices that do not have suspend blockers, a normal application runs
> in a manner similar to a hypothetical Android application that acquires
> a suspend blocker when it starts and holds that suspend blocker until
> it exits. In contrast with Android, this situation requires that each
> and every application be carefully written to avoid battery drain,
> which I suspect is what Ted is getting at with his King Canute analogy.

Which is flawed and not the case. The same argument could be made for
multi-tasking

DOS "Each application implements its own internal
multitasking/polling if needed"

Windows 3.x "Each application has an event loop and is built
in a certain way" (the 'suspend blocker' mentality)

Real OS "The scheduler operates in a manner which prevents
CPU hogs breaking the system or abusing it sufficiently to threaten its
functionality"

The same applies to power. Only the OS has the big picture and can hide
the hardware and general policy variety from the application.

OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
runs on virtual machines, it runs in power sensitive environments, it
runs in thermally constrained environments, it runs in I/O constrained
environments, it runs in latency constrained environments etc etc

All the same code, true some work has been done to make it behave
politely but the rest is down to the OS doing its job - deploying the
resources available while considering and obeying the constraints
present, in a manner which makes best use of the resources to achieve the
policy goals of the system.

And not unsurprisingly that all starts to look like Stafford Beer's good
old viable systems model.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/