On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote:
> On Sun, 6 Jun 2010 12:46:01 +0200
> Florian Mickler <florian@xxxxxxxxxxx> wrote:
>
> > On Sun, 6 Jun 2010 12:00:47 +0200
> > Vitaly Wool <vitalywool@xxxxxxxxx> 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?
James
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
