Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Paul E. McKenney on 2 Aug 2010 10:10
On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 20:03:04 -0700
> "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote:
> > > on application programmers to do the right thing. That's not to
> > > say that we shouldn't give up on trying to influence application
> > > programmers --- but relying on that as the only strategy seems to
> > > depart from the path of wisdom.
> >
> > Unless someone can reliably automate whacking the moles, history is
> > not on the side of the mole-whackers. I won't say that such
> > automation is impossible, but only because of all the "impossible"
> > things in my lifetime that have turned out to be possible.
>
> we have a few things going for us here though
>
> 1) It's easy to programatically detect the problems
> 1a) so programmers can detect issues before they ship software,
> unlike the fsync() thing Ted mentions. History is showing this is at
> least relatively successful in open source, but not with Adobe's
> proprietary software such as Flash
> 2) Users can be made aware of what the bad guys are
> 3) The business models of many of the mobile apps gives programmers a
> strong incentive to ship well behaving. The moment your first and
> second review of your app read "this app was identified as reducing
> battery life a lot"... your revenues will not go beyond the $1.98..
> ... assuming these first two guys didn't refund their app.
>
> Since we can detect who the bad guys are, we can also automatically
> quarantine them for the common cases..... which is good news.

Unless of course the app reducing battery life a lot does something
that users like better than the increment in battery life.

> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore.... at least on the Intel side it's good enough to use pretty
> much all the time (when the screen is off for now, but that's a memory
> controller issue more than anything else). I'm pretty sure the ARM guys
> will not be far behind.

Heh! One could make the "might be temporary" argument against any new
feature, including the ones that you are proposing. For but one example,
I very well remember being told by many people in many communities that
SMP was temporary -- Moore's-Law increases in clock frequency would soon
mean that even the biggest systems would be uniprocessors.

If by "memory controller" you are referring to the need to save state
for cache SRAMs and perhaps also DRAM, then yes, I agree that some of
the most difficult low-power-state tradeoffs involve these devices.

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: Paul E. McKenney on 2 Aug 2010 10:20
On Sun, Aug 01, 2010 at 08:06:55PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 18:10:06 -0700
> "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote:
>
> > If I understand you correctly, a key point of agreement between you
> > and the Android guys is that both the system and the user have some
> > say over how applications are treated by the system in terms of how
> > seriously the system takes a given application's requests.
> >
> > The Android guys also want the user to have some say about what
> > applications are permitted to have some control over "I want to go to
> > <this magic deep idle state>" requests. Does that seem reasonable
> > to you?
>
> I personally think it's one of those things where... well we can get a
> LONG way automatically (by just observing things); asking the users
> is very very often just caving in rather than solving the problem.
>
> Asking the user should only be done for things the user
> 1) Can give an intelligent answer to
> and
> 2) Are something the user WANTS to be involved in.
> (rather than 'stupid thing, why don't just do the right thing'..
> think the Windows Vista security questions)

Combining this with your previous email, I believe that you are saying
that it is necessary for the user to be able to exert some control,
but that the UI design had better be sufficiently intelligent with
sufficiently good defaults that the user almost never actually -needs-
to exert such control.

If this is indeed what you are saying, I certainly agree.

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: Rafael J. Wysocki on 2 Aug 2010 10:20
On Monday, August 02, 2010, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> > I'm a little worried that this whole "I need to block suspend" is
> > temporary. Yes today there is silicon from ARM and Intel where suspend
> > is a heavy operation, yet at the same time it's not all THAT heavy
> > anymore....
>
> Part of the problem here may also be a naming problem. There are
> multiple reasons why you might want to block suspend, and it goes far
> beyond what the CPU can do.
>
> Let's give another example, from the laptop world. If you close the
> the MacBook, it "suspends". That is, all processes stop, and the CPU
> enters a sleep state. Sounds just like Linux's suspend-to-ram, right?
>
> Except for the fact that if you insert a USB cable connected to a
> iPod/iPad/iPhone, the CPU wakes up, and iTunes will do a sync, and
> then the machine goes back to sleep. And if the Mail application is
> in the middle of manipulating the IMAP mailbox, it will be allowed to
> finish what it is doing, and then the system goes to sleep.

I _think_ you can implement that with the current kernel's interfaces and
an suitable power manager in user space. At least you should be.

The question really boils down to where the "power manager" activity should be
located. Should it be in the kernel or in user space? Or is it better to have
a "collective power manager", like in the wakelocks case? Moreover, what
should the power manager be responsible for and what the kernel's role should
be in deciding what "power" state to go into?

> So in the case of both the MacBook, where the user has closed the
> laptop, and in the case of Cell Phone, where the user has pushed the
> button saying he/she's done working with the application, the _normal_
> thing to do force all processes to go to sleep, and then let the CPU
> go to sleep.
>
> But, you may have applications that are specially privileged so they
> can ignore the user command to suspend the machine.

I frankly don't think it's legitimate to overrule the user. If the user tells
us "suspend" and specifies a set of devices that can be used for wakeup, we
should follow, possibly monitoring the wakeup devices for events.

However, that doesn't apply 100% to the cell phone case, because on cell phones
the software is actually owned by the device vendor and/or the network operator
and they may want to have a mechanism to overrule the person using the phone.
That is a more general issue, though.

> Maybe it's an iTunes-like situation, where in response to some hardware
> interrupt, it's allowed to wake up, do its thing, and then go back to sleep,
> allowing the hardware to go back to sleep. Maybe it's a mail
> application that wants to wakeup every 15 minutes, suck down any new
> mail, and then go back to sleep. The suspend blocker is a way to
> achieve this --- and this has nothing to do with chip technology, but
> with a specific use case.

Assuming that your "power manager activity" will be a collective one, along the
Android lines. Still, in principle, you can obtain a functionally equivalent
behavior with the help of a power manager in user space.

Thanks,
Rafael
--
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: James Bottomley on 2 Aug 2010 13:00
On Mon, 2010-08-02 at 08:12 -0400, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 06:30:44PM -0500, James Bottomley wrote:
> > That's why you present the user with choices and report on the outcomes.
> > At the end of the day the choice becomes binary: if the mobile optimised
> > browser burns you battery on the power meter, users will either
> > uninstall and move on to the next browser or deny the current browser
> > the ability to block suspend.
>
> Or they may decide to drop the device which has much worse battery
> lifetime in favor of the hardware that seems to do a much better job
> of controlling power overall... which is why if the Nokia folks want
> to claim that suspend blockers are no good, it's probably not going to
> change what ships with Android, and may be better power management
> strategy win. :-)
>
> > Right, but this comes back to the axes of control. They have to be
> > presented to the user in a simple but meaningful manner.
>
> In the general case, at least for today, I think it's useful if
> applications are told, "you are on AC mains", "you are on cell phone
> battery", "you are on a laptop battery". And from a user's
> perspective, I suspect if you are wanting something simple but
> meaningful, it's probably a single linear scale ranging between
> "performance optimized" and "power optimized", with maybe 1-3
> points in between.

Actually, I don't necessarily agree with this. In fact, I think it's a
dangerous proposition. The reason is that the only class of
applications I've seen usefully made power aware are some of the system
housekeeping ones (as in don't index my man pages, prelink my binaries
etc. when I'm on battery power). Perhaps I could see things that have
to poll (like imap without push support on the server) do a "poll when
woken else every X minutes", but the potential for annoying the user by
doing the wrong thing on power environment change is huge.

> Advanced users will want a much finer level of control, though --- I
> can imagine having a number of different sliders that control the
> tradeoff between power vs. performance on a number of different
> scales: networking, GPS performance, scheduler control, schreen
> brightness, etc.
>
> Android phones have a very simplified version of this widget, which
> allows you to toggle GPS on/off, bluetooth on/off, etc. And the GPS
> toggle is a good example of what I'm talking about. If you disable
> the GPS, then even if the application wants to use GPS, tough luck; it
> will have to settle for the less precise cell tower triangulation
> method. Again, it's the _user_ who gets the final say, not the
> application --- and that's as it should be.

Yes and no; agree about the user not the application but ... I actually
find the current five android "power" toggles to be largely useless. If
I don't want GPS killing my battery, I don't start GPS using
applications, for instance rather than disabling GPS. I think this
represents the "axis" problem again ... I like to manage my power in a
particular way, and others want to manage it in different ways.

James


--
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: Ted Ts'o on 2 Aug 2010 14:50
On Mon, Aug 02, 2010 at 11:51:20AM -0500, James Bottomley wrote:
> Actually, I don't necessarily agree with this. In fact, I think it's a
> dangerous proposition. The reason is that the only class of
> applications I've seen usefully made power aware are some of the system
> housekeeping ones (as in don't index my man pages, prelink my binaries
> etc. when I'm on battery power). Perhaps I could see things that have
> to poll (like imap without push support on the server) do a "poll when
> woken else every X minutes", but the potential for annoying the user by
> doing the wrong thing on power environment change is huge.

Sure, but that's why you need to let the user choose. They can decide
between, "behave as if you were on AC", and "try to save power as much
as possible", and maybe one or two points in between, and let them
choose how much performance/battery life they are willing to give up.
If they are on a long flight to Europe/Australia with no power, they
might choose a very different tradeoff point than if they know they
are only going to be in the meeting room for an hour before they can
recharge their battery.

The point is you can annoy users by burning power to improve their
"user experience" just as much as you can annoy users by trying to sip
power as delicately as possible. It's true that many applications
don't do a lot in this space, but that's mainly becaue of application
laziness. Which is why I really don't buy Arjan's whack-a-mole
approach to solving the problem. I *know* I can save tons of power by
doing "killall -STOP firefox" when I don't need to use the browser.
I've don't the power management when I've been carefully nursing my
battery while at a conference. So I have no problem if the system
does that automatically for me when I switch to a different virtual
console --- in fact, I'd prefer it! Similarly, having tools which
forcibly choose different pm_qos settings, even if it's not what the
applications want, is things that *can* very much make a difference.

So yes, maybe applications won't do much with that. But that just
reinforces the argument that it's the framework or the kernel that
needs to do these sorts of things, because the application programers
won't.

- 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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....