From: Nick Alcock <nick.alcock@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
DTrace mailing lists <dtrace@lists.linux.dev>,
dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] io: adjust io provider for NFS tracepoint variants
Date: Wed, 08 Jan 2025 11:34:36 +0000 [thread overview]
Message-ID: <87ed1dh73n.fsf@esperi.org.uk> (raw)
In-Reply-To: <474ca7db-5d3c-0426-7b17-fb04043544c5@oracle.com> (Eugene Loh's message of "Wed, 8 Jan 2025 01:01:28 -0500")
On 8 Jan 2025, Eugene Loh uttered the following:
> You already have a R-b, it seems the code is right (woo hoo! cool), and we're trying to get a release out the door. But here are my
> "late to the party" comments. Feel free to ignore.
Ditto :)
> The names v1 and v2 strike me as funny; they just make up new numbers. Not a big deal, but ideally the names might more closely
> reflect the actual version changes we're tracking.
Agreed.
> Breaking the function out into a new "v1" version is some unneeded copy-and-paste code bloat, I think. The function is kind of
> large and the only difference between v1 and v2 is I guess in the two, relatively short, "start" sections. So, keeping this stuff
> as one function -- with extra logic in the two "start" sections -- might be more compact and clearer than having two rather similar
> functions.
Agreed, but more generally it seems we are growing increasingly many
fairly similar fake bio functions in the io provider: with this I think
we're up to three. Maybe it's time to refactor some of this into some
sort of shared fake bio machinery? Certainly if we grow more I think we
should (and given the number of network filesystems, that seems quite
likely to happen).
> On 1/7/25 17:44, Kris Van Hees wrote:
>> Kernels prior to 5.6.0 pass 3 arguments (derived from the NFS hdr)
>> to the nfs_initiate_read raw tracepoint, whereas kernels as of 5.6.0
>> pass just the NFS hdr.
>
> Is the same true of write? If so, then maybe say so and point out that what we're really doing is changing the handling of nfs
> "start" while leaving nfs "done" alone... that would correspond more closely to what is happening in the code, which talks of start
> and done.
Good thinkiing. That would be commit
5bb2a7cb9fe58d2b1efedd6058d442c7871c45ec ("NFS: Clean up generic
writeback tracepoints"), also by Trond, also first landing in 5.6-rc1.
Same sort of thing.
next prev parent reply other threads:[~2025-01-08 11:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 22:44 [PATCH] io: adjust io provider for NFS tracepoint variants Kris Van Hees
2025-01-08 1:47 ` Elena Zannoni
2025-01-08 6:01 ` Eugene Loh
2025-01-08 11:34 ` Nick Alcock [this message]
2025-01-09 18:18 ` Kris Van Hees
2025-01-09 18:15 ` Kris Van Hees
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=87ed1dh73n.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@oracle.com \
--cc=kris.van.hees@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.