DPDK patches and discussions
 help / color / mirror / Atom feed
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 17:48:25 +0700 (ICT)	[thread overview]
Message-ID: <001a01d3b470$0f015a00$2d040e00$@viettel.com.vn> (raw)
In-Reply-To: <ad21aec8-2060-2ce6-5b48-d0b6d45be2e6@intel.com>

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]
> Sent: Monday, March 5, 2018 5:16 PM
> To: longtb5@viettel.com.vn; 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 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]
> >> Sent: Friday, March 2, 2018 2:19 PM
> >> To: dev@dpdk.org
> >> Cc: david.hunt@intel.com; mhall@mhcomputing.net;
> >> helin.zhang@intel.com; 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
> >

  reply	other threads:[~2018-03-05 10:48 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 [this message]
2018-03-05 11:25       ` Hunt, David
2018-03-05 12:23         ` longtb5
  -- 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='001a01d3b470$0f015a00$2d040e00$@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).