From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4832F72637 for ; Thu, 31 Jul 2025 17:04:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753981485; cv=none; b=VAe8Zp47VTx34X284OuWfkzwqqJphzj/D/UW+bwn9Lfa6pyKqEvZL9pvM10YGH/vsKAcEfQb1ij8HxOiRlcqNMqF7SGCMWLeBd9kqfKVUGk7zJNqTGZYCs0sgMUQpV8WQqPWmo/BCjaPa4GmtAp89XcHz8iLQ0JtfZQWJdR5FtA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753981485; c=relaxed/simple; bh=n8Qdtkc2uaQ3V/P1xf5ScOY3vxjdEbsxY/wA4OTqP7U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z0J1bwvUjn6lVuLQcwbUMgnAyOg9x5HLlCpVfzOVYGeyH6Kw5UEkxEpgxcxo+Z+KOo5PPbB3cqsPHB7Onk/rknszSHHF7YGviyQnnGaSkbsviLUrwrjnXhRUn/0NRRD83pvakLgkhmrBLePK6QGVTM1EzH+cpKD49P8lbtstHj8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aELc4JH6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aELc4JH6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E19E4C4CEEF; Thu, 31 Jul 2025 17:04:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753981485; bh=n8Qdtkc2uaQ3V/P1xf5ScOY3vxjdEbsxY/wA4OTqP7U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aELc4JH6otbPCJ36+o2SV+r66ua0dY/vwTrAszQnUiQcTWG351KMv6HGlgrNN/J5m jeaMh7RCyVyZ9FoueHTWWnc4x6eYZBvK6H9mrEdcOJTji+zj6yaHWGlJN6u8qtfuiF H9B4rbGHY+0pTP3lk1WhmGXaf9cem4zuMer7dDErSn5nViGcl8E/7DHfEYoaeIu3RQ I2DVo9PWNhyCTSK9zCGHeaecV91qADbun7IlM1lDwQrrMRcKKXZTpAMdmGnYeECET1 Ca88Wp0pdjm2myEiD/SPWuuv3JCWqgxZr4fVD5zb8xrk9N4ii+zJIa42BvbTsCze+9 SNS2ElqhKE8jw== Date: Thu, 31 Jul 2025 13:04:43 -0400 From: Mike Snitzer To: Jeff Layton Cc: Chuck Lever , linux-nfs@vger.kernel.org Subject: Re: [PATCH 1/3] NFSD: rename and update nfsd_read_vector_dio trace event to nfsd_analyze_dio Message-ID: References: <20250730230524.84976-1-snitzer@kernel.org> <20250730230524.84976-2-snitzer@kernel.org> <19f157f743681fe8bb28279747248b0c3ca7b81c.camel@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19f157f743681fe8bb28279747248b0c3ca7b81c.camel@kernel.org> 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 > > > > 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 > > --- > > 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. Could be good, could be bad. But if I should be taking your feedback as: "do what Jeff suggested", that's fine too, happy to do so! ;) Thanks, Mike