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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKohponVBjvQf-5BibzDUko=fVtzPYWMOr2xywp=r0TTB_t6Bw@mail.gmail.com>
Date:	Thu, 20 Jun 2013 10:31:30 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Lukasz Majewski <l.majewski@...sung.com>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Lukasz Majewski <l.majewski@...ess.pl>,
	Andre Przywara <andre.przywara@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Amit Daniel Kachhap <amit.daniel@...sung.com>
Subject: Re: [PATCH v3 1/3] cpufreq: Add boost frequency support in core

On 18 June 2013 18:56, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Tuesday, June 18, 2013 12:12:13 PM Viresh Kumar wrote:
>> On 17 June 2013 19:21, Lukasz Majewski <l.majewski@...sung.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. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/