re: Enforce _PPC limits

re: Enforce _PPC limits

[Linda Knippers]

Hi Srinivas,

I have a couple of questions about this patch set.
http://comments.gmane.org/gmane.linux.power-management.general/75263

Sorry I'm a bit late to the party but I've just booted 4.6 on my system
and noticed some things.

My first question is about enabling the feature by default on enterprise
and performance servers.  Is there any way to disable it on these servers?
I didn't see a way.  I'm always nervous when something starts looking at
a table that perhaps wasn't used before or introduces a new behavior that
might be unexpected.  Having a way out or not making it the default for a
while would be nice.

My second question is about the 48 instances I got of this when I booted my
2 socket, 48-CPU box:

> intel_pstate: _PPC limits will be enforced

I suppose in theory I could have limits for some CPUs and not others but
even in that case, the message isn't helpful.  I think it should be made
useful or go away, or at least only be printed once.

Thanks,

-- ljk

Re: Enforce _PPC limits

[Srinivas Pandruvada]

Hi Linda,

On Tue, 2016-05-24 at 16:37 -0400, Linda Knippers wrote:
> Hi Srinivas,
> 
> I have a couple of questions about this patch set.
> http://comments.gmane.org/gmane.linux.power-management.general/75263
> 
> Sorry I'm a bit late to the party but I've just booted 4.6 on my
> system
> and noticed some things.
> 
> My first question is about enabling the feature by default on
> enterprise
> and performance servers.  Is there any way to disable it on these
> servers?
> I didn't see a way.  I'm always nervous when something starts looking
> at
> a table that perhaps wasn't used before or introduces a new behavior
> that
> might be unexpected.  Having a way out or not making it the default
> for a
> while would be nice.
If you were using acpi-cpufreq ever , this would have been active
anyway.
This was requested by some server vendors to turn on by default as they
want to be able to use node manager to control and don't want to have
any kernel command line addition.

Don't you want to be able to use _PPC to control. If you don't use _PPC
then this will not be effective.
You can turn off from kernel command line processor.ignore_ppc=1

> 
> My second question is about the 48 instances I got of this when I
> booted my
> 2 socket, 48-CPU box:
> 
> > intel_pstate: _PPC limits will be enforced
> I suppose in theory I could have limits for some CPUs and not others
> but
> even in that case, the message isn't helpful.  I think it should be
> made
> useful or go away, or at least only be printed once.
> 
Agree, I will downgrade the message to pr_debug.

Thanks,
Srinivas
> 
> Thanks,
> 
> -- ljk
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enforce _PPC limits

[Linda Knippers]

Hi Srinivas,

On 5/24/2016 6:11 PM, Srinivas Pandruvada wrote:
> Hi Linda,
> 
> On Tue, 2016-05-24 at 16:37 -0400, Linda Knippers wrote:
>> Hi Srinivas,
>>
>> I have a couple of questions about this patch set.
>> http://comments.gmane.org/gmane.linux.power-management.general/75263
>>
>> Sorry I'm a bit late to the party but I've just booted 4.6 on my
>> system and noticed some things.
>>
>> My first question is about enabling the feature by default on
>> enterprise and performance servers.  Is there any way to disable it on these
>> servers?  I didn't see a way.  I'm always nervous when something starts looking
>> at a table that perhaps wasn't used before or introduces a new behavior
>> that might be unexpected.  Having a way out or not making it the default
>> for a while would be nice.

> If you were using acpi-cpufreq ever , this would have been active
> anyway.

In that case we're probably ok with the tables.

> This was requested by some server vendors to turn on by default as they
> want to be able to use node manager to control and don't want to have
> any kernel command line addition.

I can understand the desire to avoid more knobs.

> Don't you want to be able to use _PPC to control. If you don't use _PPC
> then this will not be effective.
> You can turn off from kernel command line processor.ignore_ppc=1

I guess I've lost track of what intel_pstate is doing these days.  When it
first came out, it totally disregarded ACPI information, which is why code
was added to not load the driver on some platforms that are doing their
own power management.  The rationale for not using ACPI was that ACPI
couldn't express all the information necessary to describe the hardware
capabilities.

Now it is using ACPI information for some things, but not all things?
Perhaps intel_pstate.txt could be updated to clarify that?  Depending
on what the future is for intel_pstate and ACPI, I'm wondering if that
vendor-specific code is no longer needed.

This might be a nit but I'm also confused about whether it's really
enforcing _PPC limits or _PSS.  Are you actually limiting based on
the _PPC value?

>>
>> My second question is about the 48 instances I got of this when I
>> booted my
>> 2 socket, 48-CPU box:
>>
>>> intel_pstate: _PPC limits will be enforced
>> I suppose in theory I could have limits for some CPUs and not others
>> but
>> even in that case, the message isn't helpful.  I think it should be
>> made
>> useful or go away, or at least only be printed once.
>>
> Agree, I will downgrade the message to pr_debug.

Thanks.

-- ljk
> 
> Thanks,
> Srinivas
>>  
>> Thanks,
>>
>> -- ljk
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enforce _PPC limits

[Srinivas Pandruvada]

Hi Linda,

[...]

> I guess I've lost track of what intel_pstate is doing these
> days.  When it
> first came out, it totally disregarded ACPI information, which is why
> code
> was added to not load the driver on some platforms that are doing
> their
> own power management.  The rationale for not using ACPI was that ACPI
> couldn't express all the information necessary to describe the
> hardware
> capabilities.
> 
> Now it is using ACPI information for some things, but not all things?
> Perhaps intel_pstate.txt could be updated to clarify that?
>  Depending
> on what the future is for intel_pstate and ACPI, I'm wondering if
> that
> vendor-specific code is no longer needed.
> 
> This might be a nit but I'm also confused about whether it's really
> enforcing _PPC limits or _PSS.  Are you actually limiting based on
> the _PPC value?
_PPC is an index into _PSS, the max frequency we will get from _PSS. We
are not enforcing any limits in _PSS. So if some P-State is missing in
_PSS, we will still select that P-State.
I don't know what vendor specific code does. I guess it does more than
just what acpi-cpufreq would have done.

I will check on the documentation part.

Thanks,
Srinivas

Re: Enforce _PPC limits

[Linda Knippers]

Hi Srinivas,

On 5/25/2016 1:01 PM, Srinivas Pandruvada wrote:
> Hi Linda,
> 
> [...]
> 
>> I guess I've lost track of what intel_pstate is doing these
>> days.  When it
>> first came out, it totally disregarded ACPI information, which is why
>> code
>> was added to not load the driver on some platforms that are doing
>> their
>> own power management.  The rationale for not using ACPI was that ACPI
>> couldn't express all the information necessary to describe the
>> hardware
>> capabilities.
>>
>> Now it is using ACPI information for some things, but not all things?
>> Perhaps intel_pstate.txt could be updated to clarify that?
>>  Depending
>> on what the future is for intel_pstate and ACPI, I'm wondering if
>> that
>> vendor-specific code is no longer needed.
>>
>> This might be a nit but I'm also confused about whether it's really
>> enforcing _PPC limits or _PSS.  Are you actually limiting based on
>> the _PPC value?
> _PPC is an index into _PSS, the max frequency we will get from _PSS. We
> are not enforcing any limits in _PSS. So if some P-State is missing in
> _PSS, we will still select that P-State.
> I don't know what vendor specific code does. I guess it does more than
> just what acpi-cpufreq would have done.

The vendor specific code just prevents intel-pstate from running on systems
that don't expose the p-states through ACPI.  For HP ProLiant, we don't
populate _PSS if the firmware is configured to do the power management and
in that case, we didn't want intel_pstate also doing power management.
Oracle does something similar but different.

With apci-cpufreq, if there is no p-state information exposed through ACPI,
the driver doesn't run so there is no conflict.

>From what you said, we probably still need the vendor-specific code.

> I will check on the documentation part.

Thanks,

-- ljk
> 
> Thanks,
> Srinivas
> 
>