public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Wang <00107082@163.com>
To: viro@zeniv.linux.org.uk, brauner@kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	surenb@google.com, David Wang <00107082@163.com>
Subject: [PATCH] seq_file: copy as much as possible to user buffer in seq_read()
Date: Fri, 20 Dec 2024 12:16:05 +0800	[thread overview]
Message-ID: <20241220041605.6050-1-00107082@163.com> (raw)

seq_read() yields only seq_file->size bytes to userspace, even when user
buffer is prepare to hold more data. This causes lots of extra *read*
syscalls to fetch data from /proc/*.
For example, on an 8-core system, cat /proc/interrupts needs three
*read*:
	$ strace -T -e read cat /proc/interrupts  > /dev/null
	...
	 43 read(3, "            CPU0       CPU1     "..., 131072) = 4082 <0.000068>
	 44 read(3, "  75:   13490876          0     "..., 131072) = 2936 <0.000148>
	 45 read(3, "", 131072)                     = 0 <0.000010>
On a system with hundreds of cpus, it would need tens of more read call.
A more convincing example is /proc/allocinfo, which is available when
CONFIG_MEM_ALLOC_PROFILING=y. When cat /proc/allocinfo, 4k+ lines need ~100
read calls.

This patch try to fill up user buffer as much as possible, extra read
calls can be avoided, and 2%~10% performance improvement would be
observed:
	$ strace -T -e read cat /proc/interrupts  > /dev/null
	...
	 56 read(3, "            CPU0       CPU1     "..., 131072) = 7018 <0.000208>
	 57 read(3, "", 131072)                     = 0 <0.000010>

Signed-off-by: David Wang <00107082@163.com>
---
 fs/seq_file.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 8bbb1ad46335..2cda43aec4a2 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -220,6 +220,7 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 		if (m->count)	// hadn't managed to copy everything
 			goto Done;
 	}
+Restart:
 	// get a non-empty record in the buffer
 	m->from = 0;
 	p = m->op->start(m, &m->index);
@@ -282,6 +283,11 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 	copied += n;
 	m->count -= n;
 	m->from = n;
+	/*
+	 * Keep reading in case more data could be copied into user buffer.
+	 */
+	if (m->count == 0)
+		goto Restart;
 Done:
 	if (unlikely(!copied)) {
 		copied = m->count ? -EFAULT : err;
-- 
2.39.2


             reply	other threads:[~2024-12-20  4:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20  4:16 David Wang [this message]
2024-12-20 12:13 ` [PATCH] seq_file: copy as much as possible to user buffer in seq_read() Markus Elfring
2024-12-20 13:54   ` David Wang
2024-12-20 14:08 ` [PATCH v2] " David Wang
2024-12-20 14:34   ` Markus Elfring
2024-12-20 16:48     ` David Wang

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=20241220041605.6050-1-00107082@163.com \
    --to=00107082@163.com \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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