From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Robin Jarry" <rjarry@redhat.com>, <dev@dpdk.org>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>,
"Jerin Jacob" <jerinj@marvell.com>,
"Kevin Laatz" <kevin.laatz@intel.com>,
"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>,
"Mattias Rönnblom" <hofors@lysator.liu.se>
Subject: RE: [RFC PATCH 2/4] eal: allow applications to report their cpu utilization
Date: Wed, 23 Nov 2022 12:52:31 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D874ED@smartserver.smartshare.dk> (raw)
In-Reply-To: <20221123101931.1688238-3-rjarry@redhat.com>
> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Wednesday, 23 November 2022 11.19
> To: dev@dpdk.org
> Cc: Bruce Richardson; Jerin Jacob; Kevin Laatz; Konstantin Ananyev;
> Mattias Rönnblom; Morten Brørup; Robin Jarry
> Subject: [RFC PATCH 2/4] eal: allow applications to report their cpu
> utilization
>
> Allow applications to register a callback that will be invoked in
> rte_lcore_dump() and when requesting lcore info in the telemetry API.
>
> The callback is expected to return a number between 0 and 100
> representing the percentage of busy cycles spent over a fixed period of
> time. The period of time is configured when registering the callback.
>
> Cc: Bruce Richardson <bruce.richardson@intel.com>
> Cc: Jerin Jacob <jerinj@marvell.com>
> Cc: Kevin Laatz <kevin.laatz@intel.com>
> Cc: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Cc: Mattias Rönnblom <hofors@lysator.liu.se>
> Cc: Morten Brørup <mb@smartsharesystems.com>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> ---
This patch simply provides a function for the application to register a constant X and a callback, which returns Y.
X happens to be a duration in seconds.
Y can be a number between 0 and 100, and happens to be the lcore business (to be calculated by the application).
So I agree that it contains no controversial calculations. :-)
However, if the lcore business is supposed to be used for power management or similar, it must have much higher resolution than one second.
Also, CPU Usage is often reported in multiple time intervals, e.g. /proc/loadavg provides 1, 5 and 10 minute load averages.
Perhaps a deeper issue is that the output could also be considered statistics, which is handled differently in different applications. E.g. the statistics module in the SmartShare StraightShaper application includes histories in multiple time resolutions, e.g. 5 minutes in 1-second intervals, up to 1 year in 1 day intervals.
On the other hand, if the application must expose 1/5/10 minute statistics, it could register a callback with a 1 minute interval, and aggregate the numbers it its own statistics module.
Here's completely different angle, considering how statistics is often collected and processed by SNMP based tools:
This patch is based on a "gauge" (i.e. the busyness percentage) and an "interval" (i.e. the duration the gauge covers). I have to sample this gauge exactly every interval to collect data for a busyness chart. If the application's reporting interval is 1 second, I must sample the gauge every second, or statistical information will be lost.
Instead, I would prefer the callback to return two counters: units_passed (e.g. number of cycles since application start) and units_busy (e.g. number of busy cycles since application start).
I can sample these at any interval, and calculate the busyness of that interval as the difference: (units_busy - units_busy_before) / (units_passed - units_passed_before).
If needed, I can also sample them at multiple intervals, e.g. every 1, 5 and 10 minutes, and expose in the "loadavg".
I can also sample them every millisecond if I need to react quickly to a sudden increase/drop in busyness.
next prev parent reply other threads:[~2022-11-23 11:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 10:19 [RFC PATCH 0/4] lcore telemetry improvements Robin Jarry
2022-11-23 10:19 ` [RFC PATCH 1/4] eal: add lcore info in telemetry Robin Jarry
2022-11-23 10:19 ` [RFC PATCH 2/4] eal: allow applications to report their cpu utilization Robin Jarry
2022-11-23 11:52 ` Morten Brørup [this message]
2022-11-23 13:29 ` Robin Jarry
2022-11-23 16:38 ` Stephen Hemminger
2022-11-23 10:19 ` [RFC PATCH 3/4] testpmd: add show lcores command Robin Jarry
2022-11-24 0:54 ` fengchengwen
2022-11-23 10:19 ` [RFC PATCH 4/4] testpmd: report lcore usage Robin Jarry
2022-11-23 10:44 ` [RFC PATCH 0/4] lcore telemetry improvements Robin Jarry
2022-11-23 10:26 Robin Jarry
2022-11-23 10:26 ` [RFC PATCH 2/4] eal: allow applications to report their cpu utilization Robin Jarry
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=98CBD80474FA8B44BF855DF32C47DC35D874ED@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=jerinj@marvell.com \
--cc=kevin.laatz@intel.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=rjarry@redhat.com \
/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).