Re: [PATCH 2/2 V8] intel_pstate: add kernel parameter to force loading.

From: Linda Knippers
Date: Sat Dec 06 2014 - 12:36:45 EST


On 12/5/2014 9:16 PM, ethan wrote:
> Linda,
>
>> 在 2014年12月6日,00:09,Linda Knippers <linda.knippers@xxxxxx> 写道:
>>
>>> On 12/5/2014 4:40 AM, Ethan Zhao wrote:
>>> To force loading on Oracle Sun X86 servers, provide one kernel command line
>>> parameter
>>>
>>> intel_pstate = force
>>>
>>> For those who be aware of the risk of no power capping capabily working and
>>> try to get better performance with this driver.
>>>
>>> Signed-off-by: Ethan Zhao <ethan.zhao@xxxxxxxxxx>
>>> Tested-by: Alexey Kodanev <alexey.kodanev@xxxxxxxxxx>
>>> ---
>>> v2: change to hardware vendor specific naming parameter.
>>> v4: refine code and doc.
>>> v5&v6: fix a typo in doc.
>>> v7: change enum PCC to PPC.
>>> v8: change the name of kernel command line parameter to generic one.
>>>
>>> Documentation/kernel-parameters.txt | 5 +++++
>>> drivers/cpufreq/intel_pstate.c | 6 +++++-
>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>> index 479f332..7d0983e 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -1446,6 +1446,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>> disable
>>> Do not enable intel_pstate as the default
>>> scaling driver for the supported processors
>>> + force
>>> + Enable intel_pstate on systems where it may cause problems to
>>> + happen due to conflicts with platform firmware attempting to
>>> + drive P-states by itself in certain situations (for thermal
>>> + control or power capping in general or other purposes).
>>
>> I suggest something like:
>> Enable intel_pstate on systems that prohibit it by
>> default in favor of acpi-cpufreq. Forcing the
>> intel_pstate driver instead of acpi-cpufreq may disable
>> platform features, such as thermal controls and power
>> capping, that rely on ACPI p-state information being
> P-States
>> Used by the OS and therefore should be used with care.
> Indicated to OSPM caution
>> This option does not work with processors that aren't
>> supported by the intel_pstate driver or on platforms
>> that use pcc-cpufreq instead of acpi-cpufreq.
>>
>> Maybe this is too specific but I believe it is accurate. Comments?
>>
>
> Looks better to me, except some words commented.

Your suggestions look fine to me.

-- ljk
>
> Thanks,
> Ethan
>> -- ljk
>>
>>>
>>> intremap= [X86-64, Intel-IOMMU]
>>> on enable Interrupt Remapping (default)
>>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
>>> index 1bb62ca..2654e13 100644
>>> --- a/drivers/cpufreq/intel_pstate.c
>>> +++ b/drivers/cpufreq/intel_pstate.c
>>> @@ -866,6 +866,7 @@ static struct cpufreq_driver intel_pstate_driver = {
>>> };
>>>
>>> static int __initdata no_load;
>>> +static unsigned int force_load;
>>>
>>> static int intel_pstate_msrs_not_valid(void)
>>> {
>>> @@ -1003,7 +1004,8 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
>>> case PSS:
>>> return intel_pstate_no_acpi_pss();
>>> case PPC:
>>> - return intel_pstate_has_acpi_ppc();
>>> + return intel_pstate_has_acpi_ppc() &&
>>> + (!force_load);
>>> }
>>> }
>>>
>>> @@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
>>>
>>> if (!strcmp(str, "disable"))
>>> no_load = 1;
>>> + if (!strcmp(str, "force"))
>>> + force_load = 1;
>>> return 0;
>>> }
>>> early_param("intel_pstate", intel_pstate_setup);
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/