linux-kernel - Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor

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: <8856294.KaD55h4g0a@vostro.rjw.lan>
Date:	Mon, 27 May 2013 14:00:58 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Lukasz Majewski <l.majewski@...sung.com>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
	linux-pm@...r.kernel.org,
	Vicent Guittot <vincent.guittot@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	Lukasz Majewski <l.majewski@...ess.pl>
Subject: Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

On Monday, May 27, 2013 11:03:38 AM Viresh Kumar wrote:
> On 24 May 2013 16:50, Lukasz Majewski <l.majewski@...sung.com> wrote:
> >> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@...sung.com> wrote:
> 
> > This is not safe IMHO to add permanently overclocked frequency to the
> > freq table. Since, for example, thermal framework also asks for
> > reference to this table.
> 
> Yes, its wrong. Even adding it permanently this way would be a problem
> if governor is changed to performance. :)
> 
> > The idea beneath overclocking is to add "dangerous" frequency to the
> > frequency table only when necessary (and remove it when not needed).
> 
> Hmm.. probably the idea beneath is to use dangerous frequency only
> when we are assured that we will not break system.. It doesn't have
> anything to do with cpufreq table entries :)
> 
> > In this way, the thermal framework (as it is done at our platform) will
> > decrease the frequency (according to thermal governor :-) ) to safe
> > level.
> >
> > Overclocking is disabled in 2 ways (at our setup):
> > - thermal framework is here to help us
> > - lab governor disables the overclocking when favorable conditions are
> >   gone.
> 
> I don't want to discuss OR think about LAB for now.. Want to get
> overclocking feature in first.
> 
> > One more remark - enabling tb_en_over_clk at sysfs (echo 1
> >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
> > adds overclock frequency to frequency table and updates policy.
> 
> What if it is enabled and governor is changed to performance
> without disabling it... Who will take care of disabling dangerous
> frequencies?
> 
> One thing I am certain about is to make overclocking a generic and
> core feature, rather than platform specific...
> 
> What about adding overdrive frequencies in freq table permanently
> but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ??
> 
> This way we will use frequencies marked with
> CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking
> enabled. And not at other times?

Well, this really looks like software turbo modes, so let's call them
"TURBO" instead of "OVERDRIVE" and I seem to remember having a switch for
disabling/enabling turbo modes already.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/