From: David Laight <David.Laight@ACULAB.COM>
To: 'Subhashini Rao Beerisetty' <subhashbeerisetty@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: RE: latency
Date: Sat, 4 Dec 2021 14:34:04 +0000 [thread overview]
Message-ID: <3b914a515b1d4e749e58d3b46cf12b26@AcuMS.aculab.com> (raw)
In-Reply-To: <CAPY=qRQJ-YbRi0AStrytsE3ke4vFN9K4Cos2T+b1JKDPJGUVOg@mail.gmail.com>
From: Subhashini Rao Beerisetty <subhashbeerisetty@gmail.com>
> Sent: 03 December 2021 17:01
>
> [ Please keep me in CC as I'm not subscribed to the list]
>
> Hi all,
>
> We are using the Linux OS on an x86_64 machine. I need to measure the
> PCIe latency on my system, does kernel have any latency measurement
> module for the PCIe bus?
Slower than you expect :-)
Writes are asynchronous so really only limited by the actual speed
of the PCIe link and the rate the slave can process them.
So the actual latency of writes doesn't matter and the throughput
is reasonable.
Reads are much more problematic.
While the PCIe bus allows multiple outstanding read requests the
Intel x86 I've tested will only generate one outstanding request
for each cpu core.
So buffer reads are particularly slow.
The delays between on read completing and the next read TLP being
sent are (probably) negligible compared to the other delays.
So the latency of a read is just the time the two TLP take to
be transmitted over the wire (including delays for PCIe bridges)
plus the time the slave takes to generate the response TLP.
On the fpga slaves we are using that is (from memory) about 128
cycles of the 62.5MHz clock - ie absolutely ages.
For reads you definitely need to use the largest register size
possible - each read instruction (even misaligned ones) generates
exactly one read TLP.
If you are designing an interface for an fpga then consider using
writes from both sides for everything except bulk data.
You can (probably) measure the latency of your actual system using:
x = rdtsc();
v = readl();
lfence;
elapsed = rdtsc() - x;
However the TSC values depend on the current cpu frequency (which
will change 'randomly').
Or put the readl() into a loop and do enough that the high-res
system time delts makes sense.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-12-04 14:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 17:00 PCI: latency Subhashini Rao Beerisetty
2021-12-04 8:18 ` Greg KH
2021-12-04 14:34 ` David Laight [this message]
2021-12-06 19:39 ` Bjorn Helgaas
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=3b914a515b1d4e749e58d3b46cf12b26@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=subhashbeerisetty@gmail.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