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

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: <2394846.9qggnDATev@vostro.rjw.lan>
Date:	Thu, 04 Jul 2013 14:50:13 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Lukasz Majewski <l.majewski@...sung.com>,
	"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>,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <eduardo.valentin@...com>
Subject: Re: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs

On Thursday, July 04, 2013 10:36:53 AM Viresh Kumar wrote:
> Hi Lukasz,
> 
> Sorry for being late. Actually I didn't had an answer to your mail
> and wanted to go through it with some fresh mind. This is my
> first mail this morning, lets see if I can bring something good
> into the discussion.
> 
> On 1 July 2013 13:45, Lukasz Majewski <l.majewski@...sung.com> wrote:
> > Does anybody have any idea here? As written above, thermal is suitable
> > to disable boost.
> 
> See, one thing is very clear. User space applications aren't responsible
> for enabling boost again and again. There has to be a internal mechanism
> inside kernel for that.
> 
> > I'd like to bring those three options under discussion:
> >
> > 1. boost attr is always exported -> do not enable boost automatically
> >    when disabled by thermal (as it was proposed at v4).
> 
> So, that's a problem. I see one more solution to that.
> - Create another Macro in cpufreq.c which would contain the time
> after which we will autoenable boost.

Well, how can we tell what time is correct here?  It may depend on factors not
under our control or even variable, like the ambient temperature, so surely
it might not be a hard coded value.

> - So, suppose thermal disabled it due to high temperature (Lets not
> change value of sysfs variable boost_enable, but create another
> variable like: skip_boost: which means skip boost temporarily).

What about "block_boost"?  Other than that, this particular item is a good idea
I think.

> - Thermal would enable this variable skip_boost.
> - Then we will continue to get requests for next frequency and will
> check eveytime if we have exceeded time for autoenabling boost.
> - If yes, then we disable this variable and start boosting again..

I wonder if we could use thermal watermarks instead?  Such that a high
watermark would cause block_boost to be set and a low watermark would cause
it to be reset?  And the thermal layer would be in control of both watermarks?

> - Then thermal can disable it again later.

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/