Re: [PATCH v3 1/3] cpufreq: Add boost frequency support in core

[Viresh Kumar <viresh.kumar@linaro.org>]

On 18 June 2013 18:56, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, June 18, 2013 12:12:13 PM Viresh Kumar wrote:
>> On 17 June 2013 19:21, Lukasz Majewski <l.majewski@samsung.com> wrote:

>> According to my understanding, boost was important for power
>> saving. In case a high load can be managed by a single cpu with
>> boost freqs, then its better to use boost freqs rather than bringing
>> another cpu up.
>
> Do you mean the 'boost' sysfs attribute or the 'turbo frequencies' concept?

I thought they are the. Probably not, but I am not sure about the
difference.

>> Normally boost freqs are not so useful if we talk about powersaving,
>> as their energy consumption is much higher with not so great impact
>> on performance.
>
> Er, er, please be careful here.  The impact on performance may be sufficient
> for deep C-states to become relevant in some cases.

Hmm.

>> That's why when this thread started we talked about boost only when
>> one cpu is operational. But with your patch all cores can use boost
>> freq and thermal will come into picture just to save the chip.
>
> Well, that's why on x86 turbo is controlled by hardware that takes care of
> keeping things within the chip's thermal limits.

Yeah.

>> That's wrong. This isn't why we invented boost here. Otherwise you
>> just don't need boost feature at all for your SoC. Just make these
>> freqs as available freqs and let thermal control policy->max/min
>> to save your chip.
>
> The 'boost' attribute added by acpi-cpufreq means "let the hardware use turbo
> frequencies".
>
> I'd recommend you both to read Documentation/cpu-freq/boost.txt now. :-)

I did it now :)

> I think we can extend the meaning to "let turbo frequencies be used", but if
> we need software to play the role of the hardware's thermal control, we need
> to be very careful.

Exactly. There are two variants now:
- Hardware boost: x86: Don't do any trick in software to prevent hardware
from boosting... Let the hardware take control as it is today
- Software boost: The initial idea from Lukasz was about using boost only
when one cpu is used. That's the impression I had in mind. And it looked
sensible too to some extent. BUT there is a great chance that any mistake
can burn chips, so we need to be extremely careful.

>> What we probably need is:
>> - Enabled boost from sysfs if required (now below steps will come into
>>   picture)
>
> This has to be compatible with the existing stuff.

Sure.

>> - See how many cpus are running, if only one then start using boost freqs
>> - Now thermal should be come into picture to save chip in case a single
>> cpu running at boost can burn it out.
>
> I'd say there needs to be a separate controller/monitor for that that will
> know what the chip's thermal limit is and how that relates to how fast the
> CPU core(s) may run and for how much time.  I'm not sure it is sufficient
> to "wait for thermal to kick in" here, because you may need to slow down
> things in advance (i.e. before thermal sensors tell you there's too much heat,
> because that may be too late already).

That's why I wasn't sure about software boosting initially. But at the same
time a thermal sensor might be good enough. They just have to be programmed
accordingly, so that they fire a bit in advance before things are out of
control. :)