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: <20150302174054.GB15351@e104805>
Date:	Mon, 2 Mar 2015 17:40:54 +0000
From:	Javi Merino <javi.merino@....com>
To:	Eduardo Valentin <edubezval@...il.com>
Cc:	"rui.zhang@...el.com" <rui.zhang@...el.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Punit Agrawal <Punit.Agrawal@....com>,
	"lina.iyer@...aro.org" <lina.iyer@...aro.org>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"tixy@...aro.org" <tixy@...aro.org>,
	Kapileshwar Singh <Kapileshwar.Singh@....com>
Subject: Re: [PATCH v3 0/5] Subject: The power allocator thermal governor

On Mon, Mar 02, 2015 at 05:28:50PM +0000, Eduardo Valentin wrote:
> On Mon, Mar 02, 2015 at 05:17:18PM +0000, Javi Merino wrote:
> > *** BLURB HERE ***
> > 
> > Hi linux-pm,
> > 
> > Introduce the power allocator governor, a thermal governor that
> > allocates device power to control temperature.  This series is based
> > on branch "linus" of Eduardo's linux-soc-thermal tree:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> > 
> > Changes since v2:
> >   - Address Eduardo's review
> >     + Turn variable-size array in divvy_up_power() into a
> >       devm_kcalloc() as suggested by Eduardo
> >     + Remove #ifdeffery from thermal_core.c as suggested by Eduardo
> >   - Bring back cpufreq's CPUFREQ_UPDATE_POLICY_CPU notifier in order
> >     to update the cpu device in cpu_cooling.c when cpufreq changes
> >     the policy cpu.
> 
> 
> Can you please elaborate a bit more on the issue you saw to decide to
> bring this functionality back?

I explained it in patch 5 ("thermal: cpu_cooling: update the cpu
device when cpufreq updates the policy cpu"): When cpufreq changes the
policy cpu, the cpufreq cooling device needs to update the cached cpu
device accordingly.

> Can we keep the cpufreq changes as a separated thread? To me if the
> issue happens to power allocator, it also happens to the other
> governors.

The cached cpu device was introduced in patch 98ea0816118f ("thermal:
cpu_cooling: implement the power cooling device API") in your tree.
I'm posting it here because it only affects doesn't affect other
governors.

> I don't want to block power allocator due to the cpufreq
> changes.

You don't have to.  It's the last two patches precisely for that.  You
can merge everything up to patch 3 without depending on cpufreq
changes.

> Besides, cpufreq changes should go via the proper cpufreq tree, not the
> thermal tree.

It's a change to cpu_cooling (patch 5) that needs a revert of cpufreq
(patch 4).  The change to cpu_cooling depends on the patches already
in your branch.  So you will have to carry this patch in your branch
with an Ack from the cpufreq maintainers.

Cheers,
Javi
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ