From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] Revert Jan's patch (c/s 18879) since nowitcanbe achieved by xenpm tool now Date: Tue, 23 Dec 2008 09:34:42 +0000 Message-ID: <4950BEC2.76E4.0078.0@novell.com> References: <706158FABBBA044BAD4FE898A02E4BC21C7FDD9F@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Jinsong Liu Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 23.12.08 10:06 >>> >On 23/12/2008 09:02, "Liu, Jinsong" wrote: > >> It's fine to me to keep cmdline parse to select cpufreq governor. >> I will update my patch, final result is: >> 1. keep Jan's patch (c/s 18879); >> 2. add governor setting at cmdline; >> 3. set xen as default cpufreq; >> 4. set userspace as default governor; >> 5. if user set governor at cmdline --> if gov startup success, then = cpufreq >> run it; if gov startup fail, then cpufreq back to default safe = governor; >> Is it OK? > >Sounds fine to me. Let's see what Jan thinks too. I'm okay with this too, though I'm not entirely clear why the userspace governor would be safer/better than the performance one (in particular, I'm unclear why the latter - supposedly not playing with frequencies at all - has dependencies on certain tables to be loaded successfully). But I admit that I didn't get around to look at the recent code changes, yet. Jan