On 18 June 2013 18:56, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Tuesday, June 18, 2013 12:12:13 PM Viresh Kumar wrote: >> On 17 June 2013 19:21, Lukasz Majewski <l.majewski@xxxxxxxxxxx> 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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
