On 03/06/2015 19:51, Jan Beulich wrote
> >>> On 03.06.15 at 10:07, wrote:
> > On 26/05/2015 22:02, Jan Beulich wrote
> >> >>> On 13.05.16 at 09:51, wrote:
> >> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > --- a/xen/arch/x86/acpi/cpufreq/intel
On 26/05/2015 22:16, Jan Beulich wrote
> >>> On 13.05.16 at 09:51, wrote:
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -261,29 +272,47 @@ static int get_cpufreq_para(struct
> xen_sysctl_pm_op *op)
> > op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_fre
On 04/06/2015 09:18, Wei Wang wrote
> On 03/06/2015 19:51, Jan Beulich wrote
> > >>> On 03.06.15 at 10:07, wrote:
> > > On 26/05/2015 22:02, Jan Beulich wrote
> > >> >>> On 13.05.16 at 09:51, wrote:
> > >> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > >> > +++ b/xen/arch/x86/acpi/cpufreq/cpufre
On 05/06/2015 15:22, Jan Beulich wrote
> >>> "Wang, Wei W" 06/04/15 4:21 AM >>>
> >On 26/05/2015 22:16, Jan Beulich wrote
> >> >>> On 13.05.16 at 09:51, wrote:
> >> > --- a/xen/drivers/acpi/pmstat.c
> >> > +++ b/xen
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +static int byt_get_min_pstate(void)
> > +{
> > +u64 value;
> > +
> > +rdmsrl(BYT_RATIOS, value);
> > +return (value >> 8) & 0x7F;
> > +}
> > +
> > +static int byt_get_max_pstate(void)
> > +{
> > +u64 val
On 08/06/2015 14:50, Jan Beulich wrote:
> >>> On 08.06.15 at 03:47, wrote:
> > On 26/05/2015 21:58, Jan Beulich wrote
> >> >>> On 13.05.16 at 09:50, wrote:
> >> > +static int byt_get_min_pstate(void) {
> >> > +u64 value;
> >> > +
> >> > +rdmsrl(BYT_RATIOS, value);
> >> > +return (valu
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
> > +limits.no_turbo = 0;
> > +limits.max_perf_pct = 100;
> > +limits.max_perf = int_tofp(1);
> > +limits.min_perf_pct = 100;
> > +
Hi Julien,
On 11/06/2015 22:02, Julien Grall wrote:
> On 11/06/2015 04:27, Wei Wang wrote:
> > diff --git a/xen/include/acpi/cpufreq/cpufreq.h
> b/xen/include/acpi/cpufreq/cpufreq.h
> > index d10e4c7..71bb45c 100644
> > --- a/xen/include/acpi/cpufreq/cpufreq.h
> > +++ b/xen/include/acpi/cpufreq/cp
On 11/06/2015 22:06, Julien Grall wrote:
> On 11/06/2015 04:28, Wei Wang wrote:
> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we change
> > to NULL it after the call of cpufreq_driver->exit. Otherwise, a
> > calltrace will show up on your screen due to the reference of a NULL
> >
On 11/06/2015 22:02, Julien Grall wrote:
> On 11/06/2015 04:31, Wei Wang wrote:
> > -list_for_each(pos, &cpufreq_governor_list)
> > +if (policy->policy)
>
> What if another cpufreq decides to use policy->policy?
What is "another cpufreq"? The "policy" is per-CPU struct.
> > +gov
On 12/06/2015 19:14, Julien Grall wrote:
> On 11/06/2015 23:03, Wang, Wei W wrote:
> > On 11/06/2015 22:02, Julien Grall wrote:
> >> On 11/06/2015 04:31, Wei Wang wrote:
> >>> -list_for_each(pos, &cpufreq_governor_list)
> >>> +if (policy->
On 12/06/2015 19:30, Julien Grall wrote:
> On 11/06/2015 21:41, Wang, Wei W wrote:
> > On 11/06/2015 22:02, Julien Grall wrote:
> >> On 11/06/2015 04:27, Wei Wang wrote:
> >>> diff --git a/xen/include/acpi/cpufreq/cpufreq.h
> >> b/xen/include/acpi/cpufreq
On 12/06/2015 19:40, Julien Grall wrote:
> On 11/06/2015 22:01, Wang, Wei W wrote:
> > On 11/06/2015 22:06, Julien Grall wrote:
> >> On 11/06/2015 04:28, Wei Wang wrote:
> >>> cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we
> >>> change t
On 15/06/2015 17:15, Jan Beulich wrote:
> >>> On 15.06.15 at 02:30, wrote:
> > On 12/06/2015 19:14, Julien Grall wrote:
> >> On 11/06/2015 23:03, Wang, Wei W wrote:
> >> > On 11/06/2015 22:02, Julien Grall wrote:
> >> >> On 11/06/2015
On 15/06/2015 20:37, Jan Beulich wrote:
> >>> On 15.06.15 at 14:28, wrote:
> > On 15/06/2015 17:15, Jan Beulich wrote:
> >> >>> On 15.06.15 at 02:30, wrote:
> >> > We actually want it be intel_pstate specific. If maintainers agree,
> >> > I think renaming it to intel_pstate_policy is a good optio
On 15/06/2015 20:37, Jan Beulich wrote:
> >>> On 15.06.15 at 14:28, wrote:
> > On 15/06/2015 17:15, Jan Beulich wrote:
> >> >>> On 15.06.15 at 02:30, wrote:
> >> > We actually want it be intel_pstate specific. If maintainers agree,
> >> > I think renaming it to intel_pstate_policy is a good optio
On 17/06/2015 15:54, Jan Beulich wrote:
> >>> On 16.06.15 at 09:09, wrote:
> > On 15/06/2015 20:37, Jan Beulich wrote:
> >> >>> On 15.06.15 at 14:28, wrote:
> >> > On 15/06/2015 17:15, Jan Beulich wrote:
> >> >> >>> On 15.06.15 at 02:30, wrote:
> >> >> > We actually want it be intel_pstate speci
Hi Jan,
On 11/06/2015 16:31, Wei Wang wrote:
> Add support in the pmstat.c so that the xenpm tool can request to access the
> intel_pstate driver.
I want to propose some other changes here to commonize the intel_pstate
implementation in this common code (pmstat.c).
1) introduce a new struct:
On 18/06/2015 22:30, Jan Beulich wrote:
> >>> On 11.06.15 at 10:27, wrote:
> > Register the CPU hotplug notifier when the driver is registered, and
> > move the driver register function to the cpufreq.c.
>
> The first half of the sentence fails to say why. And I suppose if you
> explained
> that
On 19/06/2015 17:44, Jan Beulich wrote:
> >>> On 11.06.15 at 10:28, wrote:
> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we change
> > to NULL it after the call of cpufreq_driver->exit. Otherwise, a
> > calltrace will show up on your screen due to the reference of a NULL
> > poin
On 23/06/2015 15:31, Jan Beulich wrote:
> >>> On 23.06.15 at 05:40, wrote:
> > On 18/06/2015 22:30, Jan Beulich wrote:
> >> >>> On 11.06.15 at 10:27, wrote:
> >> > -static int __init cpufreq_presmp_init(void)
> >> > +int cpufreq_register_driver(struct cpufreq_driver *driver_data)
> >> > {
> >> >
On 23/06/2015 16:08, Jan Beulich wrote:
> >>> On 23.06.15 at 08:16, wrote:
> > On 19/06/2015 17:44, Jan Beulich wrote:
> >> >>> On 11.06.15 at 10:28, wrote:
> >> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we
> >> > change to NULL it after the call of cpufreq_driver->exit.
> >>
On 23/06/2015 16:11, Jan Beulich wrote:
> >>> On 23.06.15 at 10:01, wrote:
> > On 23/06/2015 15:31, Jan Beulich wrote:
> >> >>> On 23.06.15 at 05:40, wrote:
> >> > On 18/06/2015 22:30, Jan Beulich wrote:
> >> >> >>> On 11.06.15 at 10:27, wrote:
> >> >> > -static int __init cpufreq_presmp_init(vo
On 23/06/2015 09:41, Wei Wang wrote:
> On 11/06/2015 16:31, Wei Wang wrote:
> > Add support in the pmstat.c so that the xenpm tool can request to
> > access the intel_pstate driver.
>
> I want to propose some other changes here to commonize the intel_pstate
> implementation in this common code (pm
On 25/06/2015 19:34, Jan Beulich wrote
> >>> On 25.06.15 at 13:14, wrote:
> > Add a common interface for matching the current cpu against an array
> > of x86_cpu_ids. Also change mwait-idle.c to use it.
> >
> > v4 changes:
> > None.
> >
> > Signed-off-by: Wei Wang
>
> Please avoid re-sending pat
On 07/07/2015 20:14, Wei Liu wrote:
> On Tue, Jul 07, 2015 at 01:05:21PM +0100, Jan Beulich wrote:
> > >>> On 07.07.15 at 10:55, wrote:
> > > On Thu, Jun 25, 2015 at 07:19:05PM +0800, Wei Wang wrote:
> > >> --- a/tools/libxc/include/xenctrl.h
> > >> +++ b/tools/libxc/include/xenctrl.h
> > >> @@ -2
On 08/07/2015 14:24, Jan Beulich wrote:
> >>> On 08.07.15 at 07:15, wrote:
> > On 07/07/2015 20:14, Wei Liu wrote:
> >> On Tue, Jul 07, 2015 at 01:05:21PM +0100, Jan Beulich wrote:
> >> > >>> On 07.07.15 at 10:55, wrote:
> >> > > On Thu, Jun 25, 2015 at 07:19:05PM +0800, Wei Wang wrote:
> >> > >
Appologies if you received multiple emails of this patch. Just couldn't see it
showing up in the mailinglist.
Best,
Wei
On 28/04/2015 16:37, Wei Wang wrote
> Changes:
> *NO.1 The intel_pstate driver can be controlled via two ways:
> A. min_perf_pct and max_perf_pct
>The user directly adjust
Hi Jan,
> On 28/04/2015 16:37, Wei Wang wrote
> > Changes:
> > *NO.1 The intel_pstate driver can be controlled via two ways:
> > A. min_perf_pct and max_perf_pct
> >The user directly adjusts min_perf_pct and max_perf_pct to get what
> >they want. For example, if min_perf_pct=max_perf_pct=6
On 15/05/2015 15:17, Jan Beulich wrote
> >>> On 15.05.15 at 08:50, wrote:
> > Hi Jan,
> >
> >> On 28/04/2015 16:37, Wei Wang wrote
>
> This looks wrong - the mail you seem to reply to is dated May 13th in my
> inbox. While I realize that I never got to reply to the v1 series (which may
> indeed h
On 18/05/2015 19:18, George Dunlap wrote
> On Fri, May 15, 2015 at 8:46 AM, Wang, Wei W
> wrote:
> >> > Do you have any comments on this version?
> >>
> >> Eventually I will. But as recently noted elsewhere, there are way too
> >> many things needin
On 26/05/2015 20:51, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > The unregister notifier function is needed to support cpu hotplug.
>
> Without loadable module support I have some difficulty seeing why this
> should be needed.
>
Ok. Then, should we remove the entire cpufreq_unregis
On 26/05/2015 21:00, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > --- a/xen/drivers/cpufreq/utility.c
> > +++ b/xen/drivers/cpufreq/utility.c
> > @@ -456,6 +456,11 @@ int __cpufreq_set_policy(struct cpufreq_policy
> > *data,
> >
> > data->min = policy->min;
> > data->max = po
On 26/05/2015 21:06, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > Register/unregister the CPU hotplug notifier when the driver is
> > registered, and move the driver register/unregister function to the
> > cpufreq.c.
>
> Without saying why I'm afraid I don't even see much reason to re
On 26/05/2015 21:17, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +extern int cpufreq_register_driver(struct cpufreq_driver
> > +*driver_data); extern int cpufreq_unregister_driver(struct
> > +cpufreq_driver *driver);
>
> Oh, btw, please also get rid of "extern" on function declaratio
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +static inline int ceiling_fp(int32_t x) {
> > +int mask, ret;
>
> Please here and below, consider whether types really need to be signed.
> One exception: If you intend to import the Linux source file with minimal
On 29/05/2015 16:46, Jan Beulich wrote
> >>> On 29.05.15 at 10:19, wrote:
> > On 26/05/2015 21:58, Jan Beulich wrote
> >> >>> On 13.05.16 at 09:50, wrote:
> >> > +static int intel_pstate_verify_policy(struct cpufreq_policy
> >> > +*policy) {
> >> > +cpufreq_verify_within_limits(policy, policy
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +id = x86_match_cpu(intel_pstate_cpu_ids);
> > +if (!id)
> > +return -ENODEV;
> > +
> > +cpu_info = (struct cpu_defaults *)id->driver_data;
> > +
> > +copy_pid_params(&cpu_info->pid_policy);
> > +
On 26/05/2015 22:02, Jan Beulich wrote
> >>> On 13.05.16 at 09:51, wrote:
> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > --- a/xen/arch/x86/acpi/cpufreq/intel_pstate.c
> > +++ b/xen/arch/x86/acpi/cpufreq/intel_pstate.c
> > @@ -766,6 +766,8 @@ static
On 24/07/2015 22:16, Jan Beulich wrote:
>>> On 25.06.15 at 13:17, wrote:
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -315,8 +315,18 @@ struct xen_get_cpufreq_para {
> uint32_t scaling_cur_fre
On 09/09/2015 16:32, Jan Beulich wrote:
>>> On 09.09.15 at 10:11, wrote:
> On 24/07/2015 22:16, Jan Beulich wrote:
On 25.06.15 at 13:17, wrote:
>> --- a/xen/drivers/acpi/pmstat.c
>> +++ b/xen/drivers/acpi/pmstat.c
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>>
On 09/09/2015 17:02, Jan Beulich wrote:
>>> On 09.09.15 at 10:49, wrote:
> On 09/09/2015 16:32, Jan Beulich wrote:
On 09.09.15 at 10:11, wrote:
>> On 24/07/2015 22:16, Jan Beulich wrote:
> On 25.06.15 at 13:17, wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pms
On 09/09/2015 18:10, Jan Beulich wrote:
>>> On 09.09.15 at 11:35, wrote:
>> Using the drinking vessel analogy, we are not putting milk and water
>> into the vessel at the same time. If the producer puts water into the
>> vessel, then the consumer simply consumes water; If the producer puts
>>
On 09/09/2015 19:57, Jan Beulich wrote:
>>> On 09.09.15 at 12:35, wrote:
> On 09/09/2015 18:10, Jan Beulich wrote:
On 09.09.15 at 11:35, wrote:
>>> Using the drinking vessel analogy, we are not putting milk and water
>>>into the vessel at the same time. If the producer puts water into th
On 09/09/2015 21:12, Jan Beulich wrote:
>>> On 09.09.15 at 14:56, wrote:
> Can you please explain more why it doesn't scale?
> From my point of view, any other future value representation can be
> passed from the producer to the related consumer through this method.
> Did you read all of my ea
On 09/09/2015 23:55, Jan Beulich wrote:
>>> On 09.09.15 at 17:16, wrote:
> On 09/09/2015 21:12, Jan Beulich wrote:
On 09.09.15 at 14:56, wrote:
>> Can you please explain more why it doesn't scale?
>> From my point of view, any other future value representation can be
>> passed from the p
On 09/09/2015 16:17, Jan Beulich wrote:
>>> On 10.09.15 at 07:35, wrote:
> On 09/09/2015 23:55, Jan Beulich wrote:
On 09.09.15 at 17:16, wrote:
>> On 09/09/2015 21:12, Jan Beulich wrote:
> On 09.09.15 at 14:56, wrote:
>>> Can you please explain more why it doesn't scale?
>>> From my
On 10/09/2015 17:55, Jan Beulich wrote:
>>> On 10.09.15 at 11:33, wrote:
> On 09/09/2015 16:17, Jan Beulich wrote:
On 10.09.15 at 07:35, wrote:
>> Seems we still cannot get rid of these strncmp()s. Is this
>> acceptable, or should we change "struct cpufreq_driver" to use enum
>> represen
On 14/09/2015 19:18, Jan Beulich wrote:
>>> On 14.09.15 at 04:42, wrote:
> By default, the old P-state driver (acpi-freq) is used. Adding
> "intel_pstate" to the Xen booting param list to enable the use of
> intel_pstate. However, if intel_pstate is enabled on a machine which
> does not suppor
On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
> > Hey,
> >
> > As far as my bisection goes, commit
> > 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
> > driver register function" prevents me from hot unplugg
On 07/10/2015 23:29, Jan Beulich wrote:
> >>> On 14.09.15 at 04:32, wrote:
> > We change to NULL the cpufreq_cpu_policy pointer after the call of
> > cpufreq_driver->exit, because the pointer is still needed in
> > intel_pstate_set_pstate().
> >
> > Signed-off-by: Wei Wang
> > ---
> > xen/drive
On 07/10/2015 11:46, Jan Beulich wrote:
> >>> On 14.09.15 at 04:32, wrote:
> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > @@ -647,9 +648,11 @@ static int __init cpufreq_driver_init(void)
> > int ret = 0;
> >
> > if ((cpufreq_controller ==
On 07/10/2015 23:46, Jan Beulich wrote:
> >>> On 14.09.15 at 04:32, wrote:
> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > @@ -647,9 +648,11 @@ static int __init cpufreq_driver_init(void)
> > int ret = 0;
> >
> > if ((cpufreq_controller ==
On 07/10/2015 23:46, Jan Beulich wrote:
> >>> On 14.09.15 at 04:32, wrote:
> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> > @@ -647,9 +648,11 @@ static int __init cpufreq_driver_init(void)
> > int ret = 0;
> >
> > if ((cpufreq_controller ==
On 23/10/2015 16:36, Jan Beulich wrote:
> >>> On 23.10.15 at 10:18, wrote:
> > On 07/10/2015 23:46, Jan Beulich wrote:
> >> >>> On 14.09.15 at 04:32, wrote:
> >> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > @@ -647,9 +648,11 @@ static int _
On 08/10/2015 12:11, Jan Beulich wrote:
> >>> On 14.09.15 at 04:32, wrote:
> > --- a/tools/libxc/xc_pm.c
> > +++ b/tools/libxc/xc_pm.c
> > @@ -260,13 +260,14 @@ int xc_get_cpufreq_para(xc_interface *xch, int
> cpuid,
> > }
> > else
> > {
> > -user_para->cpuinfo_cur_freq = s
On 26/10/2015 15:03, Jan Beulich wrote:
> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
> >On 08/10/2015 12:11, Jan Beulich wrote:
> >> >>> On 14.09.15 at 04:32, wrote:
> >> > -new_policy.governor = __find_governor(op-
> >
On 26/10/2015 17:42, Jan Beulich wrote:
> >>> On 26.10.15 at 08:59, wrote:
> > On 26/10/2015 15:03, Jan Beulich wrote:
> >> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
> >> >On 08/10/2015 12:11, Jan Beulich wrote:
> >>
On 26/10/2015 17:54, Jan Beulich wrote:
> >>> On 26.10.15 at 10:48, wrote:
> > On 26/10/2015 17:42, Jan Beulich wrote:
> >> >>> On 26.10.15 at 08:59, wrote:
> >> > On 26/10/2015 15:03, Jan Beulich wrote:
> >> >> >>>
On 26/10/2015 18:37, Jan Beulich wrote:
> >>> On 26.10.15 at 11:19, wrote:
> > On 26/10/2015 17:54, Jan Beulich wrote:
> >> That wasn't the question; I rather inquired what "meaning at the same time"
> >> both fields have.
> >
> > turbo_enable: indicates if turbo is enabled or not.
> > turbo_pct
On 26/10/2015 18:52, Jan Beulich wrote:
> >>> On 26.10.15 at 11:45, wrote:
> > On 26/10/2015 18:37, Jan Beulich wrote:
> >> >>> On 26.10.15 at 11:19, wrote:
> >> > On 26/10/2015 17:54, Jan Beulich wrote:
> >> >> That wasn't the question; I rather inquired what "meaning at the same
> time"
> >>
> > +/*
> > + * clamp_t - return a value clamped to a given range using a given
> > +type
> > + * @type: the type of variable to use
> > + * @val: current value
> > + * @lo: minimum allowable value
> > + * @hi: maximum allowable value
> > + *
> > + * This macro does no typechecking and uses tempora
On 24/07/2015 21:36, Jan Beulich wrote:
> >>> On 25.06.15 at 13:15, wrote:
> > cpufreq_add_cpu() is already called in the hypercall code path (the
> > bottom of set_px_pminfo() and inside cpufreq_cpu_init()).
> > So, we remove the redundant calling here.
>
> While I can see that currently the ca
On 24/07/2015 21:36, Jan Beulich wrote:
> >>> On 25.06.15 at 13:16, wrote:
> > Register the CPU hotplug notifier when the driver is registered, and
> > move the driver register function to the cpufreq.c.
>
> At the very least this ought to be merged with the previous patch.
>
> > --- a/xen/driv
On 24/07/2015 21:54, Jan Beulich wrote:
> >>> On 25.06.15 at 13:16, wrote:
> > +int __init intel_pstate_init(void)
> > +{
> > + int cpu, rc = 0;
> > + const struct x86_cpu_id *id;
> > + struct cpu_defaults *cpu_info;
> > +
> > + id = x86_match_cpu(intel_pstate_cpu_ids);
> > + if (!id)
>
On 23/04/2015 22:09, Jan Beulich wrote:
> >>> On 23.04.16 at 15:31, wrote:
> > The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all
> > the logic for selecting the current P-state. It follows its
> > implementation in the kernel. Instead of using the traditional cpufreq
> > govern
On 23/04/2015 15:27, Jan Beulich wrote:
> >>> On 24.04.15 at 07:12, wrote:
> > On 23/04/2015 22:09, Jan Beulich wrote:
> >> >>> On 23.04.16 at 15:31, wrote:
> >> > The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains
> >> > all the logic for selecting the current P-state. It follows
On 24/04/2015 17:11, Jan Beulich wrote:
> >>> On 24.04.15 at 10:32, wrote:
> > On 23/04/2015 15:27, Jan Beulich wrote:
> >> >>> On 24.04.15 at 07:12, wrote:
> >> > On 23/04/2015 22:09, Jan Beulich wrote:
> >> >> >>> On 23.04.16 at 15:31, wrote:
> >> >> > The intel_pstate.c file under xen/arch/x8
On 24/04/2015 17:56, Jan Beulich wrote:
> >>> On 24.04.15 at 11:46, wrote:
> > On 24/04/2015 17:11, Jan Beulich wrote:
> >> >>> On 24.04.15 at 10:32, wrote:
> >> > In the old driver, a powersave governor just sets the CPU to run
> >> > with the lowest possible performance state. This one does not
On 24/04/2015 18:20, Jan Beulich wrote
> >>> On 24.04.15 at 12:07, wrote:
> > On 24/04/2015 17:56, Jan Beulich wrote:
> >> >>> On 24.04.15 at 11:46, wrote:
> >> > On 24/04/2015 17:11, Jan Beulich wrote:
> >> >> >>> On 24.04.15 at 10:32, wrote:
> >> >> I think at the very least from a user interf
On 24/04/2015 20:57, Jan Beulich wrote
> >>> On 24.04.15 at 13:53, wrote:
> > On 24/04/2015 18:20, Jan Beulich wrote
> >> >>> On 24.04.15 at 12:07, wrote:
> >> > On 24/04/2015 17:56, Jan Beulich wrote:
> >> >> >>> On 24.04.15 at 11:46, wrote:
> >> >> > On 24/04/2015 17:11, Jan Beulich wrote:
> >
On 24/04/2015 23:04, Jan Beulich wrote
> >>> On 24.04.15 at 16:56, wrote:
> > On 24/04/2015 20:57, Jan Beulich wrote
> >> I'm not sure how else to express what I want (no matter how many
> >> internal governors the intel_pstate driver has).
> >>
> >> xenpm set-scaling-governor powersave
> >> xenpm
On 24/04/2015 23:54, Jan Beulich wrote
> >>> On 24.04.15 at 17:42, wrote:
> > On 24/04/2015 23:04, Jan Beulich wrote
> >> >>> On 24.04.15 at 16:56, wrote:
> >> > On 24/04/2015 20:57, Jan Beulich wrote
> >> >> I'm not sure how else to express what I want (no matter how many
> >> >> internal govern
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> On Fri, Apr 24, 2015 at 03:42:40PM +0000, Wang, Wei W wrote:
> > On 24/04/2015 23:04, Jan Beulich wrote
> > > >>> On 24.04.15 at 16:56, wrote:
> > > > On 24/04/2015 20:57, Jan Beulich wrote
> > >
Hi Julien,
On 24/04/2015 20:57, Julien Grall wrote
> On 23/04/2016 18:58, Wei Wang wrote:
> > diff --git a/xen/include/acpi/cpufreq/processor_perf.h
> > b/xen/include/acpi/cpufreq/processor_perf.h
> > index d8a1ba6..ebff11d 100644
> > --- a/xen/include/acpi/cpufreq/processor_perf.h
> > +++ b/xen/i
On 26/04/2015 01:33, Julien Grall wrote
Hi Julien,
> On 26/04/2015 05:32, Wang, Wei W wrote:
> > On 24/04/2015 20:57, Julien Grall wrote
> >> On 23/04/2016 18:58, Wei Wang wrote:
> >>> diff --git a/xen/include/acpi/cpufreq/processor_perf.h
> >>> b
On 28/04/2015 21:14, Jan Beulich wrote
> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> How will this affect AMD processors which can use the cpufreq? Would
> >> the ondemand feature go away?
> >
> >No, this won't affect them. When the "intel_pstate=disable" is added to
> >the booting par
On 28/04/2015 21:29, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 3:24 PM >>>
> >On 28/04/2015 21:14, Jan Beulich wrote
> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> >> How will this affect AMD processors which
On 28/04/2015 21:29, Jan Beulich wrote
>>>> "Wang, Wei W" 04/28/15 3:24 PM >>>
> >On 28/04/2015 21:14, Jan Beulich wrote
> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> >> How will this affect AMD processors which
On 29/04/2015 07:10, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 4:38 PM >>>
> >On 28/04/2015 21:29, Jan Beulich wrote
> >>>>> "Wang, Wei W" 04/28/15 3:24 PM >>>
> >> >On 28/04/2015 21:14, Jan Beulich wro
On 29/04/2015 08:11, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 3:41 PM >>>
> >Please have a check my conclusion of the changes.
>
> These look all correct, with ...
>
> >NO.2
> >The xenpm "get-cpufreq-para" will di
81 matches
Mail list logo
