[lkml]   [2010]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Thu, 27 May 2010, Matthew Garrett wrote:

    > On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
    > > On Thu, 27 May 2010, Matthew Garrett wrote:
    > > > ACPI provides no guarantees about what level of hardware functionality
    > > > remains during S3. You don't have any useful ability to determine which
    > > > events will generate wakeups. And from a purely practical point of view,
    > > > since the latency is in the range of seconds, you'll never have a low
    > > > enough wakeup rate to hit it.
    > >
    > > Right, it does not as of today. So we cannot use that on x86
    > > hardware. Fine. That does not prevent us to implement it for
    > > architectures which can do it. And if x86 comes to the point where it
    > > can handle it as well we're going to use it. Where is the problem ? If
    > > x86 cannot guarantee the wakeup sources it's not going to be used for
    > > such devices. The kernel just does not provide the service for it, so
    > > what ?
    > We were talking about PCs. Suspend-as-c-state is already implemented for
    > OMAP.

    Ah, now we talk about PCs. And all of a sudden the problem of the
    unability of determining wakeup sources is not longer relevant ? So
    how do you guarantee that we don't miss one if we cant figure out
    which ones are kept alive in S3 ?

    > > So the only thing you are imposing to app writers is to use an
    > > interface which solves nothing and does not save you any power at
    > > all.
    > It's already been demonstrated that the Android approach saves power.

    Demonstrated ? Care to explain me how it makes a difference:

    while (1) {
    ---> suspend
    <--- resume
    do_crap(); 1000000 cycles


    while (1) {
    ---> suspend
    <--- resume
    do_crap(); 1000000 cycles

    You spend the damned 10000000 cycles in any case just at a different
    point in time. So if you are so convinced and have fully understood
    all the implications, please enlighten me why do_crap() costs less
    power with the blockers approach.

    An you are also stubbornly refusing to answer my analysis about the
    effect on apps which do not use the blocker or are not allowed to.

    1) The kernel blocker does not guarantee that the lousy app has
    processed the event. It just guarantees that the lousy app has
    emptied the input queue. So what's the point of the kernel blocker
    in that case ?

    2) What's the difference on setting that app to QoS(NONE) and let the
    kernel happily ignore it.

    Come up with real explanations and numbers and not just the "it has
    been demonstrated" chant which is not holding water if you look at the

    > > Runnable tasks and QoS guarantees are the indicators whether you can
    > > go to opportunistic suspend or not. Everything else is just window
    > > dressing.
    > As I keep saying, this is all much less interesting if you don't care
    > about handling suboptimal applications. If you do care about them then
    > the Android approach works. Nobody has demonstrated a scheduler-based
    > one that does.

    That does not make the android approach any better. They should have
    talked to us upfront and not after the fact. Just because they decided
    to do that in their google basement w/o talking to people who care is
    not proving that it's a good solution and even less a reason to merge
    it as is.

    The kernel history is full of examples where crappy solutions got
    rejected and kept out of the kernel for a long time even if there was
    a need for them in the application field and they got shipped in
    quantities with out of tree patches (NOHZ, high resolution timers,
    ...). At some point people stopped arguing for crappy solutions and
    sat down and got it right. The problem of power management and
    opportunistic suspend is not different in any way.



     \ /
      Last update: 2010-05-27 20:57    [W:0.023 / U:36.924 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site