On 06/10/2022 18:32, Stephen Hemminger wrote:
On Thu, 6 Oct 2022 09:38:01 +0000
Tadhg Kearney <tadhg.kear...@intel.com> wrote:
Add API to allow uncore frequency adjustment. Uncore is a
term used by Intel to describe function of a microprocessor
that are closely connected to the core to achieve high
performance. This is done through manipulating related
uncore frequency control sysfs entries to adjust the
minimum and maximum uncore frequency values and works
on Linux for Intel hardware.
Signed-off-by: Tadhg Kearney <tadhg.kear...@intel.com>
Reviewed-by: David Hunt <david.h...@intel.com>
Acked-by: David Hunt <david.h...@intel.com>
Hi Stephen,
Looks like this is missing an opportunity for a more general
long term solution in DPDK.
We're hoping that this is the first step along the path to that
long-term solution. It's like the power library frequency control for
cores, which was initially Intel only, and then more architectures were
added over time. The API's are experimental, so can be adapted if needed.
Shouldn't this be a general thing like the Linux kernel scheduler.
I don't think the kernel scheduler has any concept of uncore busyness,
the uncore frequency is typically controlled by hardware, and if there's
enough polling going on, the frequency of the uncore will remain high
(if uncore frequency scaling is enabled). We're addressing that in this
patch in that if the application realises that it's not processing a lot
of packets even though most of it's cores are polling, it can tell the
hardware to scale down the uncore to save power.
Uncore is Intel specific, but there is already big/little cores
on many ARM platforms.
I don't think big/little is related to uncore frequency scaling. The
big/little cores still need to communicate via that architecture's
communications bus (called uncore in Intel's case, though I've seen that
term used on other architectures also). Where an architecture can scale
the frequency of this communications bus, this patch set's functionality
can be extended in the future to cover this.
Regards,
Dave