Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[mark gross]

On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> 2010/6/2 mark gross <640e9920@xxxxxxxxx>:
> > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> >> On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@xxxxxxxxx> wrote:
> >> > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> >> ...
> >> >> +static void update_target_val(int pm_qos_class, s32 val)
> >> >> +{
> >> >> +     s32 extreme_value;
> >> >> +     s32 new_value;
> >> >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> >> >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> >> >> +     if (extreme_value != new_value)
> >> >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> >> >> +}
> >> >> +
> >> >
> >> > Only works 1/2 the time, but I like the idea!
> >> > It fails to get the righ answer when constraints are reduced.  But, this
> >> > idea is a good improvement i'll roll into the next pm_qos update!
> >> >
> >>
> >> I think it would be a better idea to track your constraints with a
> >> sorted data structure. That way you can to better than O(n) for both
> >> directions. If you have a lot of constraints with the same value, it
> >> may even be worthwhile to have a two stage structure where for
> >> instance you use a rbtree for the unique values and list for identical
> >> constraints.
> >
> > I don't agree, we went through this tree vrs list discussion a few times
> > before in other areas of the kernel.  Wherever the list tended to be
> > short, a simple list wins.  However; we can try it, after we have some
> > metrics and stress test cases identified we can measure its effectivenes
> > against.
> >
> 
> The list is not short. You have all the inactive and active
> constraints on the same list. If you change it to a two level list
> though, the list of unique values (which is the list you have to walk)
> may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a
handfull.  However; one could go to a dual list (like the scheduler) and
move inactive nodes from an active to inactive list, or we could simply
remove them from the list uppon inactivity.  which would would well
after I change the api to have the client allocate the memory for the
nodes...  BUT, if your moving things in and out of a list a lot, I'm not
sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

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