Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor

[Matthew Hall <mhall@mhcomputing.net>]

Hello,

In about one month, I never received any response about all these major 
issues I was finding with librte_power and the intel_pstate based CPU 
clockrate control driver used in all the new Linux kernels.

 From what I can tell, none of this librte_power code ever worked right 
in the first place on Sandy Bridge and newer, because the chip secretly 
ignores clockrate adjustments from outside.

Can anyone who is more expert about Intel Power Management please help 
me check this and point me to some documentation which explains how this 
is supposed to work?

I am kind of blocked on doing performance / production quality 
improvements on my code, without some kind of basic help understanding 
how this librte_power stuff should work.

Thanks,
Matthew.

On 12/5/15 4:08 PM, Matthew Hall wrote:
> Hello all,
>
> I wanted to ask some questions about librte_power and the great adaptive
> polling / IRQ mode example in l3fwd-power.
>
> I am very interested in getting this to work in my project because it will
> make it much friendlier to attract new community developers if I am as
> cooperative as possible with system resources.
>
> Let's discuss the init process for a moment. It has some problems on my
> system, and I need some help to figure out how to handle this right.
>
> 1. Begins with the call to rte_power_init.
>
> 2. Attempts to init ACPI cpufreq mode.
>
> 2.1. Sets lcore cpufreq governor to userspace mode.
>
> 2.2. Function power_get_available_freqs checks lcore CPU frequencies from:
>
> /sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies
>
> 2.3. This fails with (cryptic) error "POWER: ERR: File not openned". I am
> planning to write a patch for this error a bit later.
>
> My kernel is using the intel_pstate driver, so scaling_available_frequencies
> does not exist:
>
> http://askubuntu.com/questions/544266/why-are-missing-the-frequency-options-on-cpufreq-utils-indicator
>
> 3. When power_get_available_freqs fails, rte_power_acpi_cpufreq_init fails.
>
> 4. rte_power_init will try rte_power_kvm_vm_init. That will fail because it's
> a physical Skylake system not some kind of VM.
>
> 5. Now rte_power_init totally fails, with error "POWER: ERR: Unable to set
> Power Management Environment for lcore 0".
>
> So, I have a couple of questions to figure out from here:
>
> 1. It seems bad to switch the governor into userspace before verifying the
> frequencies available in scaling_available_frequencies. If there are no
> frequencies available, it seems like it should not be trying to take over
> control of an effectively uncontrollable value.
>
> 2. If the governor is switched to userspace, and then no governing is done, it
> seems like the clockrate will necessarily always be wrong also because nothing
> will be configuring it anymore, neither kernel, nor failed DPDK userspace
> code, since rte_power_freq_up / down function pointers will always be NULL. Is
> this true? This seems bad if so.
>
> It seems that the librte_power code is basically out of date, as pstate has
> been present since Sandy Bridge, which is quite old by now for network
> processing. I am not sure how to make this work right now. So far I see a
> couple options but I really don't know much about this stuff:
>
> 1) skip rte_power_init completely, and let intel_pstate handle it using HWP
> mode
>
> 2) disable intel_pstate, switch to the legacy ACPI cpufreq (but people warned
> this old driver is mostly a no-op and the CPU ignores its frequency requests).
>
> The Internet advice says it's possible, but not a very good idea, to switch
> from the modern intel_pstate driver to the legacy ACPI mode. Reading through
> the kernel docs (below) state that it's better to use HWP (Hardware P State)
> mode:
>
> https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt
>
> If none of this rte_power_init stuff works, are the other CPU conservation
> measures inside the l3fwd-power example enough to work right with HWP all by
> themselves with nothing additional?
>
> Thanks,
> Matthew.
>