All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Xing <kerneljasonxing@gmail.com>
To: axboe@kernel.dk, rostedt@goodmis.org, mhiramat@kernel.org,
	mathieu.desnoyers@efficios.com, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	Jason Xing <kernelxing@tencent.com>,
	Yushan Zhou <katrinzhou@tencent.com>
Subject: [PATCH v1 1/5] relayfs: support a counter tracking if per-cpu buffers is full
Date: Mon, 12 May 2025 10:49:31 +0800	[thread overview]
Message-ID: <20250512024935.64704-2-kerneljasonxing@gmail.com> (raw)
In-Reply-To: <20250512024935.64704-1-kerneljasonxing@gmail.com>

From: Jason Xing <kernelxing@tencent.com>

Add 'full' field in per-cpu buffer structure to detect if the buffer is
full, which means: 1) relayfs doesn't intend to accept new data in
non-overwrite mode that is also by default, or 2) relayfs is going to
start over again and overwrite old unread data when kernel module has
its own subbuf_start callback to support overwrite mode. This counter
works for both overwrite and non-overwrite modes.

This counter doesn't have any explicit lock to protect from being
modified by different threads at the same time for the better
performance consideration. In terms of the atomic operation, it's not
introduced for incrementing the counter like blktrace because side
effect may arise when multiple threads access the counter simultaneously
on the machine equipped with many cpus, say, more than 200. As we can
see in relay_write() and __relay_write(), the writer at the beginning
should consider how to use the lock for the whole write process, thus
it's not necessary to add another lock to make sure the counter is
accurate.

Using 'pahole --hex -C rchan_buf vmlinux' so you can see this field just
fits into one 4-byte hole in the cacheline 2.

Reviewed-by: Yushan Zhou <katrinzhou@tencent.com>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 include/linux/relay.h | 9 +++++++++
 kernel/relay.c        | 8 +++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/linux/relay.h b/include/linux/relay.h
index f80b0eb1e905..022cf11e5a92 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -28,6 +28,14 @@
  */
 #define RELAYFS_CHANNEL_VERSION		7
 
+/*
+ * Relay buffer error statistics dump
+ */
+struct rchan_buf_error_stats
+{
+	unsigned int full;		/* counter for buffer full */
+};
+
 /*
  * Per-cpu relay channel buffer
  */
@@ -43,6 +51,7 @@ struct rchan_buf
 	struct irq_work wakeup_work;	/* reader wakeup */
 	struct dentry *dentry;		/* channel file dentry */
 	struct kref kref;		/* channel buffer refcount */
+	struct rchan_buf_error_stats stats; /* error stats */
 	struct page **page_array;	/* array of current buffer pages */
 	unsigned int page_count;	/* number of current buffer pages */
 	unsigned int finalized;		/* buffer has been finalized */
diff --git a/kernel/relay.c b/kernel/relay.c
index 5aeb9226e238..b5db4aa60da1 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -252,8 +252,13 @@ EXPORT_SYMBOL_GPL(relay_buf_full);
 static int relay_subbuf_start(struct rchan_buf *buf, void *subbuf,
 			      void *prev_subbuf)
 {
+	int buf_full = relay_buf_full(buf);
+
+	if (buf_full)
+		buf->stats.full++;
+
 	if (!buf->chan->cb->subbuf_start)
-		return !relay_buf_full(buf);
+		return !buf_full;
 
 	return buf->chan->cb->subbuf_start(buf, subbuf,
 					   prev_subbuf);
@@ -298,6 +303,7 @@ static void __relay_reset(struct rchan_buf *buf, unsigned int init)
 	buf->finalized = 0;
 	buf->data = buf->start;
 	buf->offset = 0;
+	buf->stats.full = 0;
 
 	for (i = 0; i < buf->chan->n_subbufs; i++)
 		buf->padding[i] = 0;
-- 
2.43.5


  reply	other threads:[~2025-05-12  2:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12  2:49 [PATCH v1 0/5] relayfs: misc changes Jason Xing
2025-05-12  2:49 ` Jason Xing [this message]
2025-05-13  0:51   ` [PATCH v1 1/5] relayfs: support a counter tracking if per-cpu buffers is full Andrew Morton
2025-05-13  1:37     ` Jason Xing
2025-05-12  2:49 ` [PATCH v1 2/5] relayfs: introduce dump of relayfs statistics function Jason Xing
2025-05-13  0:51   ` Andrew Morton
2025-05-13  1:48     ` Jason Xing
2025-05-13  2:04       ` Andrew Morton
2025-05-13  2:26         ` Jason Xing
2025-05-13  3:41           ` Andrew Morton
2025-05-13  3:48             ` Jason Xing
2025-05-13  9:58   ` Masami Hiramatsu
2025-05-13 10:32     ` Jason Xing
2025-05-13 13:22       ` Masami Hiramatsu
2025-05-13 13:46         ` Jason Xing
2025-05-14  1:29           ` Masami Hiramatsu
2025-05-14  2:06             ` Jason Xing
2025-05-12  2:49 ` [PATCH v1 3/5] blktrace: use rbuf->stats.full as a drop indicator in relayfs Jason Xing
2025-05-12  2:49 ` [PATCH v1 4/5] relayfs: support a counter tracking if data is too big to write Jason Xing
2025-05-12  2:49 ` [PATCH v1 5/5] relayfs: uniformally use possible cpu iteration Jason Xing
2025-05-13  0:52   ` Andrew Morton
2025-05-13  2:03     ` Jason Xing
2025-05-13  3:21       ` Andrew Morton
2025-05-13  3:25         ` Jason Xing
2025-05-13  5:52     ` Jason Xing

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=20250512024935.64704-2-kerneljasonxing@gmail.com \
    --to=kerneljasonxing@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=katrinzhou@tencent.com \
    --cc=kernelxing@tencent.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.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 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.