[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53EE0E5B.3050004@linux.intel.com>
Date: Fri, 15 Aug 2014 06:42:51 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Ashwin Chaugule <ashwin.chaugule@...aro.org>,
Peter Zijlstra <peterz@...radead.org>
CC: lkml <linux-kernel@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mike Turquette <mike.turquette@...aro.org>,
Morten Rasmussen <morten.rasmussen@....com>, mingo@...nel.org,
len.brown@...el.com, rjw@...ysocki.net,
"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
Arnd Bergmann <arnd@...db.de>, linux-acpi@...r.kernel.org,
cpufreq@...r.kernel.org, Patch Tracking <patches@...aro.org>,
Dirk Brandewie <dirk.brandewie@...il.com>
Subject: Re: [RFC 0/3] Experimental patchset for CPPC
On 8/15/2014 6:08 AM, Ashwin Chaugule wrote:
> (b) we come up with ways to provide the bounds around a Desired value
> using the information from the platform. (long term)
>
> I briefly looked at the x86 HWP (Hardware Performance States) in the
> s/w manual again. Its essentially an implementation of CPPC. It seems
> like X86 has implemented most if not all these registers as MSRs. I'm
> really interested in knowing if anyone there is/has been working on
> using them and what they found.
we've found that so far that there are two reasonable options
1) Let the OS device (old style)
2) Let the hardware decide (new style)
2) is there in practice today in the turbo range (which is increasingly the whole thing)
and the hardware can make decisions about power budgetting on a timescale the OS
can never even dream of, so once you give control the the hardware (with CPPC or native)
it's normally better to just get out of the way as OS.
--
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