[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |