Date:	Tue, 18 Jun 2013 12:12:13 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Lukasz Majewski <l.majewski@...sung.com>
Cc:	"Rafael J. Wysocky" <rjw@...k.pl>,
	"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 17 June 2013 19:21, Lukasz Majewski <l.majewski@...sung.com> wrote:
> On Mon, 17 Jun 2013 18:40:50 +0530, Viresh Kumar wrote:
>> >> > The core acpi-cpufreq.c code hadn't been changed by me, so I
>> >> > assume that it will work as before.
>> >>
>> >> That should adapt your patch in your patchset.
>
> Could you explain what do you mean?

Update acpi-cpufreq to use your infrastructure.

>> >> From sysfs?? I thought we are going to have some automatic control
>> >> of this stuff from inside kernel.
>> >
>> > From sysfs I just enable the boost. I do not order from userpace the
>> > cpufreq to run with a particular (boosted) frequency.
>> >
>> > When I enable boost - I ask (politely) the cpufreq core to
>> > reevaluate policies and when applicable increase policy->max.
>> >
>> > Then governor can use this new frequencies for normal operation.
>>
>> So, with your current patchset in, ondemand or conservative governors
>> will start using boost frequencies. Which might burn your chip.
>
> Two scenarios:
> 1. Thermal framework is compiled in and enabled (for exynos/other SoC)
> -> trip point is reached -> boost is disabled -> frequency is reduced ->
> SoC is cooled down.
>
> I think, that thermal framework is a good "safe valve" here.

Even in this case boost shouldn't have been enabled by default.
Its not only about burning the chip but more than that.

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.

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.

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.

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.

> 2. Thermal framework is disabled and user has enabled boost and used
> ondemand / conservative governor.
> Then execute gzip < /dev/urandom > /dev/null & (on all cores).
>
> Then yes, chip will hang/burn due to crossing operating point (or burn).
>
>
> What other means of control (despite of thermal) would you consider
> applicable?
>
> What comes to my mind is modifying governor logic to count how long the
> CPU run with boost enabled and then disable it.

Its not about how long.. One cpu type can work longer with boost freq
compared to other.

What we probably need is:
- Enabled boost from sysfs if required (now below steps will come into
  picture)
- 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.
--
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/

Powered by blists - more mailing lists