[lkml]   [2010]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] suspend blockers & Android integration
    On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote:
    > On Sun, 6 Jun 2010 12:46:01 +0200
    > Florian Mickler <> wrote:
    > > On Sun, 6 Jun 2010 12:00:47 +0200
    > > Vitaly Wool <> wrote:
    > >
    > > > Even worse, the suspend wakelock will keep the
    > > > whole kernel active, as opposed to powering off unused devices
    > > > separately as it's done in runtime PM.
    > >
    > > That is not true. While the kernel is not suspended it does
    > > runtime pm.
    > On several of our platforms runtime PM already includes suspend so a
    > suspend wakelock does interfere with existing power managemet at that
    > level (not to mention the maintenance mess it causes).
    > This is one of the reasons you want QoS information, it provides
    > parameters by which the power management code can make a decision.
    > Suspend blocksers simply don't have sufficient variety to manage the
    > direction of power policy.
    > If Android chooses to abuse the QoS information for crude suspend
    > blocking then that is fine, it doesn't interfere with doing the job
    > 'properly' on other systems or its use for realtime work on other boxes.

    Right ... and I think we can make use of this as an incremental way
    forwards. This QoS re-expression needs doing for the suspend from idle
    + cgroup approach, and it can be made to work with the current suspend
    blockers patch.

    I've already posted most of the necessary improvements to pm_qos, all of
    which end up looking like the right thing to do independent of android.
    There's really only one remaining thing, and that's adding statistics.

    Once stats are added, I think I can transform the 8 android patches into
    a set of 7 pm_qos transformations and one patch that adds the
    opportunistic suspend infrastructure. The 7 pm_qos patches should be
    reasonably uncontroversial, but what they would allow us to do is to
    unblock about 75% of the driver divergences from Qualcomm and others.
    The 1 opportunistic suspend one will be confined to one or two files, so
    is easy to maintain ... we can then argue over who should maintain it in
    the interim, us or Google.

    >From this basis, we can then proceed to look at implementing the cgroups
    + suspend from idle approach, and we can do this regardless of whether
    the opportunistic suspend patch is applied or not.

    There are three reasons why the whole debate is going in circles

    1. Lots of people are taking a holistic approach (i.e. must solve
    everything) ... this means that previously unarticulated issues
    keep cropping up that are unrelated to the current patch set ...
    but which set off another cascade of emails.
    2. There currently is no cgroups + suspend from idle approach
    implemented anywhere. That means we have to argue theoreticals
    rather than actuals (theoreticals are easy to shoot down with
    other theoretical arguments ... leading to another email
    cascade). If we implemented the thing, these arguments would
    compare one factual basis to another.
    3. We've lost sight of one of the original goals, which was to
    bring the android tree close enough to the kernel so that the
    android downstream driver and board producers don't have to
    choose between the android kernel and vanilla kernel.

    I think the proposal above gets us to within 75% of the way to 3, moves
    us towards a factual basis for 2 and eliminates some of the grounds for
    argument of 1 ... now can we please get on with it?


     \ /
      Last update: 2010-06-06 16:35    [W:0.023 / U:7.912 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site