On 17 June 2013 19:21, Lukasz Majewski <l.majewski@xxxxxxxxxxx> 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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
