Re: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs

[Lukasz Majewski]

On Thu, 27 Jun 2013 16:46:44 +0530, Viresh Kumar wrote:
> @Rafael: We need you to jump into this discussion now, I don't
> have a good idea about what we should do :)
> 
> On 27 June 2013 16:28, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote:
> > Do you have any idea of how to precisely set the load threshold?
> 
> I thought we are talking about cpu being in idle state.

If we _drop_ the idea with thermal subsystem to disable the boost,
the logic as far as I've understood shall here be as follow:

Only enable BOOST when one CPU load > THRESHOLD_MAX and other CPUs <
THRESHOLD_MIN

THRESHOLD_MIN & THRESHOLD_MAX are SoC specific. 

In my opinion the above constrain imposes policy to the cpufreq driver.

> 
> > As a side note:
> >
> > I've thought about this patch for some time and for me it looks
> > like we are mixing policy (number of busy CPUs) with abilities,
> > which shall be provided by the driver (boost).
> > Additionally, we can only roughly "estimate" [*] when boost shall
> > run and when it shall be turned off.
> 
> This is another problem in the patch you sent. User would simply
> enable or disable boost feature from userspace only once.

The above statement is definitely true for Intel. There HW manage the
frequency.

> 
> Now, if you disable it at high temperatures then its responsibility
> to enable it again. Which you are missing.

So thermal or "other solution" [*] shall disable boost when overheated
and enable it back when things cool down.

[*] @ Viresh & Rafael do you have any idea about the "other solution"
here?


> 
> > I think that, we shall leave this management [*] to the thermal
> > framework. This framework is designed exactly to protect from over
> > heating (it uses the same freq_table for passive CPU cooling) with
> > several trip points -> e.g. 40 deg (disable boost), 75 deg (impose
> > max freq as 1.0 GHz to cool down, 90 deg (shutdown immediately).
> > Please refer to PATH v4 7/7.
> 
> There might be platforms where overheating isn't a issue with boost,
> if it is only enabled while only one cpu is in use.

Could you elaborate more on this?

I thought, that with multi core one needs to keep itself inside
power/thermal dissipation envelope. 

> 
> > Unfortunately, since we dropped Kconfig flag for BOOST we cannot
> > impose "select THERMAL_FRAMEWORK", when flag for BOOST is enabled at
> > Kconfig.
> 
> Not a big deal, we can get that in if required.
> 
> > Ideally kernel shall not even build when CONFIG_CPUFREQ_BOOST
> > Kconfig flag is set and thermal for target architecture is not
> > correctly configured (including proper trip points).

This would prevent situation when somebody made a mistake and
had enabled boost, but for some reason had forgotten to
configure/enable thermal subsystem.

Moreover Kconfig's CONFIG_CPUFREQ_BOOST flag would indicate that user
enabled boost for some reason and he/she (presumably) knows what is
doing.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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/