[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 4/5] x86: allow limiting the max C-state sub-state



On Wed, Jul 03, 2019 at 01:03:02PM +0000, Jan Beulich wrote:
> From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> 
> Allow limiting the max C-state sub-state by appending to the max_cstate
> command-line parameter. E.g. max_cstate=1,0
> The limit only applies to the highest legal C-state. For example:
>   max_cstate = 1, max_csubstate = 0 ==> C0, C1 okay, but not C1E
>   max_cstate = 1, max_csubstate = 1 ==> C0, C1 and C1E okay, but not C2
>   max_cstate = 2, max_csubstate = 0 ==> C0, C1, C1E, C2 okay, but not C3
>   max_cstate = 2, max_csubstate = 1 ==> C0, C1, C1E, C2 okay, but not C3
> 
> Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Explicitly log "unlimited". Pass NULL in the 2nd simple_strtoul()
>      invocation.
> 
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1374,9 +1374,11 @@ Specify the maximum number of CPUs that
>   This option is ignored in **pv-shim** mode.
>   
>   ### max_cstate (x86)
> -> `= <integer>`
> +> `= <integer>[,<integer>]`
>   
> -Specify the deepest C-state CPUs are permitted to be placed in.
> +Specify the deepest C-state CPUs are permitted to be placed in, and
> +optionally the maximum sub C-state to be used used.  The latter only applies
> +to the highest permitted C-state.
>   
>   ### max_gsi_irqs (x86)
>   > `= <integer>`
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -104,7 +104,17 @@ bool lapic_timer_init(void)
>   
>   void (*__read_mostly pm_idle_save)(void);
>   unsigned int max_cstate __read_mostly = UINT_MAX;
> -integer_param("max_cstate", max_cstate);
> +unsigned int max_csubstate __read_mostly = UINT_MAX;
> +
> +static int __init parse_cstate(const char *s)
> +{
> +    max_cstate = simple_strtoul(s, &s, 0);
> +    if ( *s == ',' )
> +        max_csubstate = simple_strtoul(s + 1, NULL, 0);
> +    return 0;
> +}
> +custom_param("max_cstate", parse_cstate);
> +
>   static bool __read_mostly local_apic_timer_c2_ok;
>   boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
>   
> @@ -347,7 +357,13 @@ static void dump_cx(unsigned char key)
>   
>       printk("'%c' pressed -> printing ACPI Cx structures\n", key);
>       if ( max_cstate < UINT_MAX )
> +    {
>           printk("max state: C%u\n", max_cstate);
> +        if ( max_csubstate < UINT_MAX )
> +            printk("max sub-state: %u\n", max_csubstate);
> +        else
> +            printk("max sub-state: unlimited\n");
> +    }
>       else
>           printk("max state: unlimited\n");
>       for_each_present_cpu ( cpu )
> @@ -592,7 +608,13 @@ static void acpi_processor_idle(void)
>   
>           do {
>               cx = &power->states[next_state];
> -        } while ( cx->type > max_state && --next_state );
> +        } while ( (cx->type > max_state ||
> +                   cx->entry_method == ACPI_CSTATE_EM_NONE ||
> +                   (cx->entry_method == ACPI_CSTATE_EM_FFH &&
> +                    cx->type == max_cstate &&
> +                    (cx->address & MWAIT_SUBSTATE_MASK) > max_csubstate)) &&
> +                  --next_state );
> +            cx = &power->states[next_state];

Is the line above a stray addition? It is at least not properly
aligned AFAICT.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.