linux-kernel - Re: [RFC v1 0/6] CPPC as a PID backend

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] [day] [month] [year] [list]

Message-ID: <CAJ5Y-eaKeyfF8hyN3fqoKEOH-+Z8ubogGFNtsKG3g75g9qnOWA@mail.gmail.com>
Date:	Wed, 10 Sep 2014 14:21:15 -0400
From:	Ashwin Chaugule <ashwin.chaugule@...aro.org>
To:	Dirk Brandewie <dirk.brandewie@...il.com>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"rwells@...eaurora.org" <rwells@...eaurora.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Len Brown <len.brown@...el.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Subject: Re: [RFC v1 0/6] CPPC as a PID backend

On 10 September 2014 13:31, Dirk Brandewie <dirk.brandewie@...il.com> wrote:
> On 09/10/2014 09:11 AM, Ashwin Chaugule wrote:
>> On 10 September 2014 11:44, Dirk Brandewie <dirk.brandewie@...il.com>
>> With the current split I think you will still be able to maintain
>> Intel specific changes for the future in the backend driver. The PID
>> algorithm seems platform independent anyway and the PID knobs are
>> exported to userspace for platform specific tuning. The Intel backend
>> driver should be unaffected by the CPPC (ACPI) backend. We can also
>> make them mutually exclusive at runtime.
>
>
> We could make it runtime selectable whether to use CPPC or the
> native mechanisms for P state enumeration and selection but we would
> get into an awful black/white list situation that would not make
> anyone happy.
>
> Using CPPC on Intel platforms implies using HWP which is already
> planned for in intel_pstate.  I am not aware of any effort to support
> CPPC on Intel platforms that do not support HWP.  For Intel platforms
> using CPPC is NOT needed or desirable IMHO.  We had many conversations
> over many months while CPPC was being defined and made the decision
> to not use this mechanism on Intel Linux platforms.

Ok. There is no intention to force CPPC usage on Intel platforms. We
could make the CPPC backend unavailable on Intel platforms at compile
time. The idea behind this patchset is to mainly separate out the PID
algorithm so it can be used by anyone who can support it, with or
without CPPC. For ARM64 , using CPPC is useful to unify all the ARM
implementations which choose to design counters as either memory
mapped or sysregs or whatever, while keeping the PID algorithm the
same.

>>
>> Or are you suggesting using PID + CPPC as another driver? IIUC, that
>> would lead to a lot of redundancy.
>>
>
> The redundancy is actually pretty small IMHO if you take out the
> enumeration/init code the code shared at runtime is pretty small
> sample/calc_busy/PID.

This is exactly all there is in pid_ctrl.c. If HWP is enabled, do you
plan to modify these generic PID bits in a platform specific manner?
If not, then it seems that the HWP accessors could live in the intel
pid backend driver?

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