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

Date:	Wed, 10 Sep 2014 12:11:58 -0400
From:	Ashwin Chaugule <ashwin.chaugule@...aro.org>
To:	Dirk Brandewie <dirk.brandewie@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"rwells@...eaurora.org" <rwells@...eaurora.org>
Cc:	"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>
Subject: Re: [RFC v1 0/6] CPPC as a PID backend

On 10 September 2014 11:44, Dirk Brandewie <dirk.brandewie@...il.com> wrote:
> Hi Ashwin,

Hi Dirk,

>
> I think the CPPC based driver should be a separate driver.
>
> We made the conscious decision to not use any of the ACPI mechanisms
> to enumerate or control P state selection.  Experience over the years
> has shown that the quality/accuracy of the BIOS/ACPI implementations
> vary widely across OEM's and platform types from a single OEM. Features
> that always work on a server platform from a given OEM may not work or
> provide bad information on client platforms for example.
>
> Another reason for doing intel_pstate was to be able to land intel specific
> features and fixes without breaking other architectures as the power
> management capabilities of the platform evolve. As processors that support
> Hardware P states (HWP) as described in section 14.4 of the current SDM
> come into the market intel_pstate will change to not doing much other
> than enabling HWP and providing an interface to forward user configuration
> requests to the processor if the user chooses to enable HWP otherwise the
> current mechanisms will be used.  This is why the intel_pstate sysfs
> interface is the way it is to be able to map cleanly to HWP and provide
> an abstract interface going forward.
>
> Having separate drivers allows the system integrator/user to select the
> most appropriate mechanism for their system.
>
> --Dirk

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.

Or are you suggesting using PID + CPPC as another driver? IIUC, that
would lead to a lot of redundancy.

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/