From: longtb5@viettel.com.vn
To: <david.hunt@intel.com>, <dev@dpdk.org>
Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor
Date: Mon, 5 Mar 2018 19:23:25 +0700 (ICT) [thread overview]
Message-ID: <001d01d3b47d$56ac4b00$0404e100$@viettel.com.vn> (raw)
In-Reply-To: <0f17897c-590d-d405-6ae9-e79c62b0ba43@intel.com>
Hi Dave,
Unfortunately I do not have access to our server BIOS settings. The power management task for our appliance is also on pending. I'm expecting to return to this task in April. Maybe we can still work out a patch before 18.05 (not sure about DPDK roadmap).
Regards,
-BL
> -----Original Message-----
> From: david.hunt@intel.com [mailto:david.hunt@intel.com]
> Sent: Monday, March 5, 2018 6:26 PM
> To: longtb5@viettel.com.vn; dev@dpdk.org
> Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor
>
>
> Hi BL,
>
>
> On 5/3/2018 10:48 AM, longtb5@viettel.com.vn
> <mailto:longtb5@viettel.com.vn> wrote:
>
>
> Hi Dave,
>
> Actually in my test lab which is a HP box running CentOS 7 on kernel
> version
> 3.10.0-693.5.2.el7.x86_64, the default cpufreq driver is pcc_cpufreq.
> So I guess
> disabling intel_pstate wouldn't help in my case.
>
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> pcc-cpufreq
>
> # cat
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
> conservative userspace powersave ondemand performance
>
> According to kernel doc, pcc_cpufreq also doesn't export
> scaling_availabe_frequencies
> in sysfs.
>
> From kernel doc:
> "scaling_available_frequencies is not created in /sys. No intermediate
> frequencies need to be listed because the BIOS will try to achieve any
> frequency, within limits, requested by the governor. A frequency
> does not have
> to be strictly associated with a P-state."
>
> The lack of scaling_availabe_frequencies makes
> power_acpi_cpufreq_init()
> complains, similar to the problem with intel_pstate as in the other
> thread.
> I have tried (though with not much effort) to force the kernel
> to use acpi-cpufreq instead but without success.
>
> Luckily, as quoted above pcc_cpufreq supports setting of arbitrary
> frequency,
> so a simple workaround for now is to fake a
> scaling_available_frequencies file
> in another directory, then edit the code in librte_power to use that
> file instead.
>
> Regards,
> -BL
>
>
> -----Original Message-----
> From: david.hunt@intel.com <mailto:david.hunt@intel.com>
> [mailto:david.hunt@intel.com]
> Sent: Monday, March 5, 2018 5:16 PM
> To: longtb5@viettel.com.vn <mailto:longtb5@viettel.com.vn>
> ; dev@dpdk.org <mailto:dev@dpdk.org>
> Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq
> governor
>
> Hi BL,
>
> I have always used "intel_pstate=disable" in my kernel
> parameters at boot so
> as to disable the intel_pstate driver, and force the kernel to
> use the acpi-
> cpufreq driver:
>
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> acpi-cpufreq
>
> This then gives me the following options for the governor:
> ['conservative', 'ondemand', 'userspace', 'powersave',
> 'performance',
> 'schedutil']
>
> Because DPDK threads typically poll, they appear as 100%
> busy to the p_state
> driver, so if you want to be able to change core frequency
> down (as in l3fwd-
> power), you need to use the acpi-cpufreq driver.
>
> I had a read through the docs just now, and this does not
> seem to be
> mentioned, so I'll do up a patch to give some information on
> the correct
> kernel parameters to use when using the power library.
>
> Regards,
> Dave.
>
> On 2/3/2018 7:20 AM, longtb5@viettel.com.vn
> <mailto:longtb5@viettel.com.vn> wrote:
>
> Forgot to link the original thread.
>
> http://dpdk.org/ml/archives/dev/2016-
> January/030930.html
>
> -BL
>
>
> -----Original Message-----
> From: longtb5@viettel.com.vn
> <mailto:longtb5@viettel.com.vn> [mailto:longtb5@viettel.com.vn]
> Sent: Friday, March 2, 2018 2:19 PM
> To: dev@dpdk.org <mailto:dev@dpdk.org>
> Cc: david.hunt@intel.com
> <mailto:david.hunt@intel.com> ; mhall@mhcomputing.net
> <mailto:mhall@mhcomputing.net> ;
> helin.zhang@intel.com
> <mailto:helin.zhang@intel.com> ; longtb5@viettel.com.vn
> <mailto:longtb5@viettel.com.vn>
> Subject: librte_power w/ intel_pstate cpufreq
> governor
>
> Hi everybody,
>
> I know this thread was from over 2 years ago
> but I ran into the same
>
> problem
>
> with l3fwd-power today.
>
> Any updates on this?
>
> -BL
>
>
>
>
>
>
> Good to hear you found a workaround.
>
> So the issue really is "Getting the Power Library working with the ppc-cpufreq
> kernel driver" :)
>
> From wiki.archlinux.org:
> ppc-cpufreq: his driver supports Processor Clocking Control interface by
> Hewlett-Packard and Microsoft Corporation which is useful on some ProLiant
> servers.
>
> In the following doc: https://www.kernel.org/doc/Documentation/cpu-
> freq/pcc-cpufreq.txt
> it mentions - "When PCC mode is enabled, the platform will not expose
> processor performance or throttle states (_PSS, _TSS and related ACPI
> objects) to OSPM. Therefore,the native P-state driver (such as acpi-cpufreq
> for Intel, powernow-k8 forAMD) will not load".
> Is there a way to disable PPC mode in the BIOS on that server? From that
> wording, it seems to imply imply that there is a way to disable PPC (seeing that
> it can be enabled).
>
> If you can't disbale PPC, I would suggest that a patch may be needed to allow
> the power library detect if it's using acpi or ppc, and obtain a list of cpu
> frequencies accordingly. However, I don't have any HP servers available to
> me, so I'm currently unable to research a method of getting a list of valid cpu
> frequencies on a machine using the ppc driver.
>
> If you come up with a snippet of code for listing available frequencies on that
> server, let me know and we can look at adding that into the power library. :)
>
> Regards,
> Dave.
>
>
>
>
next prev parent reply other threads:[~2018-03-05 12:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 7:18 longtb5
2018-03-02 7:20 ` longtb5
2018-03-05 10:16 ` Hunt, David
2018-03-05 10:48 ` longtb5
2018-03-05 11:25 ` Hunt, David
2018-03-05 12:23 ` longtb5 [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-02-27 5:56 Threqn Peng
2017-03-01 9:22 ` Threqn Peng
2015-12-06 0:08 Matthew Hall
2016-01-03 7:51 ` Matthew Hall
2016-01-12 15:17 ` Zhang, Helin
2016-01-14 7:03 ` Matthew Hall
2016-01-14 7:11 ` Matthew Hall
2016-01-14 7:15 ` Zhang, Helin
2016-01-14 7:44 ` Matthew Hall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001d01d3b47d$56ac4b00$0404e100$@viettel.com.vn' \
--to=longtb5@viettel.com.vn \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).