From: Isaac Boukris <iboukris@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: users@dpdk.org
Subject: Re: Accuracy of rte_get_tsc_hz() compared to linux
Date: Thu, 19 Sep 2024 15:26:11 +0300 [thread overview]
Message-ID: <CAC-fF8R+4byOq3iuoZ8oxuedQZjr3XwSibruvzmy5KNOJzP+Sw@mail.gmail.com> (raw)
In-Reply-To: <20240918162739.144ffd9d@hermes.local>
On Thu, Sep 19, 2024 at 2:27 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Thu, 19 Sep 2024 01:04:40 +0300
> Isaac Boukris <iboukris@gmail.com> wrote:
>
> > I've run the helloworld application on an isolated cpu:
> > taskset -c 10 ./dpdk-helloworld --log-level=lib.eal:debug --no-huge
> >
> > The results are:
> > EAL: TSC frequency arch ~2100000 KHz
> > EAL: TSC frequency linux ~2095082 KHz
> > EAL: TSC frequency estimate ~2095346 KHz
> >
> > The arch one is picked, which seems rather wrong, any way to override that?
> > Should we lower the estimation rounding to 1MHz or even 1KHz in the linux one?
> >
> > Thoughts? Thanks!
> >
> > Kernel: 4.18.0-513.9.1.el8_9.x86_64
>
> Note: 4.18 kernel was end of life 12 August 2018, I assume
> this is RHEL8 which does their own backports and never changes kernel version.
>
> What is the kernel dmesg, why is it deciding on that value?
Actually, this is the boot dmesg on the machine itself (the previous
log was from a kvm on that machine).
# journalctl -b --system | grep -i tsc
Sep 15 17:50:16 localhost kernel: tsc: Detected 2100.000 MHz processor
Sep 15 17:50:16 localhost kernel: TSC deadline timer available
Sep 15 17:50:16 localhost kernel: clocksource: tsc-early: mask:
0xffffffffffffffff max_cycles: 0x1e4530a99b6, max_idle_ns:
440795257976 ns
Sep 15 17:50:16 localhost kernel: clocksource: Switched to clocksource tsc-early
Sep 15 17:50:16 localhost kernel: tsc: Refined TSC clocksource
calibration: 2095.082 MHz
Sep 15 17:50:16 localhost kernel: clocksource: tsc: mask:
0xffffffffffffffff max_cycles: 0x1e330abbade, max_idle_ns:
440795251159 ns
Sep 15 17:50:16 localhost kernel: clocksource: Switched to clocksource tsc
So it looks like it is refined based on calibration, which we could do
by preferring the linux estimation results over the arch (and lowering
the rounding to 1MHz). Alternatively, maybe find a way to read the
linux values or allow to set the value manually at init (as an eal
param).
next prev parent reply other threads:[~2024-09-19 12:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-18 22:04 Isaac Boukris
2024-09-18 23:27 ` Stephen Hemminger
2024-09-19 9:37 ` Isaac Boukris
2024-09-19 12:26 ` Isaac Boukris [this message]
2024-09-19 13:04 ` Isaac Boukris
2024-09-19 18:33 ` Isaac Boukris
2024-09-19 21:53 ` Stephen Hemminger
2024-09-19 22:02 ` Stephen Hemminger
2024-09-19 22:21 ` Stephen Hemminger
2024-09-20 3:19 ` Isaac Boukris
2024-09-20 14:39 ` Stephen Hemminger
2024-09-20 15:06 ` Isaac Boukris
2024-09-21 6:36 ` Isaac Boukris
2024-09-20 7:26 ` David Marchand
2024-09-20 14:36 ` Stephen Hemminger
2024-09-20 15:11 ` Isaac Boukris
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=CAC-fF8R+4byOq3iuoZ8oxuedQZjr3XwSibruvzmy5KNOJzP+Sw@mail.gmail.com \
--to=iboukris@gmail.com \
--cc=stephen@networkplumber.org \
--cc=users@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).