Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1205924 > unrolled thread

Re: [RFCv5 PATCH 18/46] arm: topology: Define TC2 energy and provide it to the scheduler

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFCv5 PATCH 18/46] arm: topology: Define TC2 energy and provide  it to the scheduler Peter Zijlstra <peterz@infradead.org> - 2015-08-12 12:40 +0200
    Re: [RFCv5 PATCH 18/46] arm: topology: Define TC2 energy and provide  it to the scheduler Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-08-12 20:50 +0200

#1205924 — Re: [RFCv5 PATCH 18/46] arm: topology: Define TC2 energy and provide it to the scheduler

On Tue, Jul 07, 2015 at 07:24:01PM +0100, Morten Rasmussen wrote:
> +static struct capacity_state cap_states_cluster_a7[] = {
> +	/* Cluster only power */
> +	 { .cap =  150, .power = 2967, }, /*  350 MHz */
> +	 { .cap =  172, .power = 2792, }, /*  400 MHz */
> +	 { .cap =  215, .power = 2810, }, /*  500 MHz */
> +	 { .cap =  258, .power = 2815, }, /*  600 MHz */
> +	 { .cap =  301, .power = 2919, }, /*  700 MHz */
> +	 { .cap =  344, .power = 2847, }, /*  800 MHz */
> +	 { .cap =  387, .power = 3917, }, /*  900 MHz */
> +	 { .cap =  430, .power = 4905, }, /* 1000 MHz */
> +	};

So can I suggest a SCHED_DEBUG validation of the data provided?

Given the above table, it _never_ makes sense to run at .cap=150, it
equally also doesn't make sense to run at .cap = 301.

So please add a SCHED_DEBUG test on domain creation that validates that
not only is the .cap monotonically increasing, but the .power is too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1206323

On 12/08/15 11:33, Peter Zijlstra wrote:
> On Tue, Jul 07, 2015 at 07:24:01PM +0100, Morten Rasmussen wrote:
>> +static struct capacity_state cap_states_cluster_a7[] = {
>> +	/* Cluster only power */
>> +	 { .cap =  150, .power = 2967, }, /*  350 MHz */
>> +	 { .cap =  172, .power = 2792, }, /*  400 MHz */
>> +	 { .cap =  215, .power = 2810, }, /*  500 MHz */
>> +	 { .cap =  258, .power = 2815, }, /*  600 MHz */
>> +	 { .cap =  301, .power = 2919, }, /*  700 MHz */
>> +	 { .cap =  344, .power = 2847, }, /*  800 MHz */
>> +	 { .cap =  387, .power = 3917, }, /*  900 MHz */
>> +	 { .cap =  430, .power = 4905, }, /* 1000 MHz */
>> +	};
> 
> So can I suggest a SCHED_DEBUG validation of the data provided?

Yes we can do that.

> 
> Given the above table, it _never_ makes sense to run at .cap=150, it
> equally also doesn't make sense to run at .cap = 301.
>

Absolutely right.


> So please add a SCHED_DEBUG test on domain creation that validates that
> not only is the .cap monotonically increasing, but the .power is too.

The requirement for current EAS code to work is even higher. We're not
only requiring monotonically increasing values for .cap and .power but
that the energy efficiency (.cap/.power) is monotonically decreasing.
Otherwise we can't stop the search for a new appropriate OPP in
find_new_capacity() in case .cap >= current 'max. group usage' because
we can't assume that this OPP will be the most energy efficient one.

For the example above we get .cap/.power = [0.05 0.06 0.08 0.09 0.1 0.12
0.1 0.09] so only the last 3 OPPs [800, 900, 1000 Mhz] make sense from
this perspective on our TC2 test chip platform.

So we should check for monotonically decreasing (.cap/.power) values.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web