From: Chuck Lever <chuck.lever@oracle.com>
To: Mike Snitzer <snitzer@kernel.org>
Cc: linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH 1/3] NFSD: rename and update nfsd_read_vector_dio trace event to nfsd_analyze_dio
Date: Thu, 31 Jul 2025 14:10:09 -0400 [thread overview]
Message-ID: <bc045a5f-c99f-47f2-8d48-ffce7befc7ab@oracle.com> (raw)
In-Reply-To: <aIuiK06UZpIlklFN@kernel.org>
On 7/31/25 1:04 PM, Mike Snitzer wrote:
> On Thu, Jul 31, 2025 at 11:31:29AM -0400, Jeff Layton wrote:
>> On Wed, 2025-07-30 at 19:05 -0400, Mike Snitzer wrote:
>>> From: Mike Snitzer <snitzer@hammerspace.com>
>>>
>>> Rename nfsd_read_vector_dio trace event to nfsd_analyze_dio and update
>>> it so that it provides useful tracing for both READ and WRITE. This
>>> prepares for nfsd_vfs_write() to also make use of it when handling
>>> misaligned WRITEs.
>>>
>>> Signed-off-by: Mike Snitzer <snitzer@hammerspace.com>
>>> ---
>>> fs/nfsd/trace.h | 37 ++++++++++++++++++++++++-------------
>>> fs/nfsd/vfs.c | 11 ++++++-----
>>> 2 files changed, 30 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/fs/nfsd/trace.h b/fs/nfsd/trace.h
>>> index 55055482f8a8..51b47fd041a8 100644
>>> --- a/fs/nfsd/trace.h
>>> +++ b/fs/nfsd/trace.h
>>> @@ -473,41 +473,52 @@ DEFINE_NFSD_IO_EVENT(write_done);
>>> DEFINE_NFSD_IO_EVENT(commit_start);
>>> DEFINE_NFSD_IO_EVENT(commit_done);
>>>
>>> -TRACE_EVENT(nfsd_read_vector_dio,
>>> +TRACE_EVENT(nfsd_analyze_dio,
>>> TP_PROTO(struct svc_rqst *rqstp,
>>> struct svc_fh *fhp,
>>> + u32 rw,
>>
>> I would do this a bit differently. You're hardcoding READ and WRITE
>> into both tracepoints. I would turn this trace event into a class a'la
>> DECLARE_EVENT_CLASS, and then just define two different tracepoints
>> (maybe trace_nfsd_analyze_read/write_dio). Then you can just drop the
>> above u32 field, and it'll still be evident whether it's a read or
>> write in the log.
>
> Seems overkill to me, and also forces the need for user to enable
> discrete tracepoints.
Users can enable trace points with globs, so that's not a big deal in
most cases. What is more important is that, when you define individual
trace points, you can enable tracing for only reads or only writes.
The common trope is to define a class, as Jeff suggested. The I/O
direction is then recorded in the trace point and the extra field
is no longer necessary.
--
Chuck Lever
next prev parent reply other threads:[~2025-07-31 18:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 23:05 [PATCH 0/3] NFSD DIRECT: add handling for misaligned WRITEs Mike Snitzer
2025-07-30 23:05 ` [PATCH 1/3] NFSD: rename and update nfsd_read_vector_dio trace event to nfsd_analyze_dio Mike Snitzer
2025-07-31 15:31 ` Jeff Layton
2025-07-31 17:04 ` Mike Snitzer
2025-07-31 18:10 ` Chuck Lever [this message]
2025-07-31 18:12 ` Mike Snitzer
2025-07-31 19:04 ` Jeff Layton
2025-07-30 23:05 ` [PATCH 2/3] NFSD: prepare nfsd_vfs_write() to use O_DIRECT on misaligned WRITEs Mike Snitzer
2025-07-30 23:05 ` [PATCH 3/3] NFSD: issue WRITEs using O_DIRECT even if IO is misaligned Mike Snitzer
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=bc045a5f-c99f-47f2-8d48-ffce7befc7ab@oracle.com \
--to=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=snitzer@kernel.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).