From: Eric Peterson <linuxinstalled@gmail.com>
To: Eric Sandeen <sandeen@sandeen.net>, linux-xfs@vger.kernel.org
Cc: Carlos Maiolino <cem@kernel.org>, Dave Chinner <dgc@kernel.org>,
linux-kernel@vger.kernel.org, eric.peterson@hpe.com,
Eric Peterson <linuxinstalled@gmail.com>
Subject: Re: [PATCH] xfs: add per-mount read/write I/O completion counters
Date: Thu, 10 Sep 2026 18:00:02 -0600 [thread overview]
Message-ID: <20260911000002.4089325-1-linuxinstalled@gmail.com> (raw)
In-Reply-To: <1c5bebcd-76f5-407f-b3af-a6170fff2497@sandeen.net>
Eric,
I have an application that sends IO through several different layers.
In my case:
Ethernet adapter -> NFS -> XFS -> Block device -> SSD
I already have visibility of qdepth/RT and IOPS at the ethernet
adapter, block dev, and SSD, but I'm missing information about what is
going on in the middle.
I wanted a "light touch" way of measuring what is going on in the middle
so that I could have hard data about the performance impact of my
changes.
As part of that "light touch", I wanted to avoid a method that would
artificially inflate metrics due to the increased load from
instrumentation.
In addition, my approach was to follow the existing code structure of
counters that were already present.
Regarding Dave's points about edge cases he illustrated, I am in
agreement with them on the technical basis.
If precision is decided to be more important than overhead, then this is
not the right course of action.
However, I disagree that the edge cases make this a "useless" way of
taking measurements.
As I shared, there are still several applications that would benefit
from this.
Regarding whether these counters get merged or not, I already have them
present in my kernel builds.
My personal needs are met.
I chose to submit a patch because I believed others could also find
benefit from them.
If the cost of the stat was cheap enough, and given the right
understanding of the caveats of this method, it was worth sharing.
-Other Eric
prev parent reply other threads:[~2026-09-11 0:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 3:34 Eric Peterson
2026-08-30 21:26 ` Dave Chinner
2026-08-31 0:47 ` Eric Peterson
2026-08-31 6:43 ` Carlos Maiolino
2026-09-02 4:25 ` [PATCH v2] " Eric Peterson
2026-08-31 9:38 ` [PATCH] " Dave Chinner
2026-09-02 5:32 ` Eric Peterson
2026-09-07 22:53 ` Dave Chinner
2026-09-09 1:09 ` Eric Sandeen
2026-09-11 0:00 ` Eric Peterson [this message]
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=20260911000002.4089325-1-linuxinstalled@gmail.com \
--to=linuxinstalled@gmail.com \
--cc=cem@kernel.org \
--cc=dgc@kernel.org \
--cc=eric.peterson@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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
all inboxes | Powered by JetHome®