[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6943003-da31-4ac7-8944-c7dc06381148@paulmck-laptop>
Date: Tue, 31 Oct 2023 15:47:44 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Davidlohr Bueso <dave@...olabs.net>,
Josh Triplett <josh@...htriplett.org>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Joel Fernandes <joel@...lfernandes.org>,
Boqun Feng <boqun.feng@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Zqiang <qiang.zhang1211@...il.com>, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org, rcu@...r.kernel.org
Subject: Re: [PATCH] refscale: Optimize process_durations()
On Tue, Oct 31, 2023 at 11:21:14AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 30, 2023 at 09:55:16AM -0700, Davidlohr Bueso wrote:
> > On Sat, 28 Oct 2023, Christophe JAILLET wrote:
> >
> > > process_durations() is not a hot path, but there is no good reason to
> > > iterate over and over the data already in 'buf'.
> > >
> > > Using a seq_buf saves some useless strcat() and the need of a temp buffer.
> > > Data is written directly at the correct place.
> >
> > Makes sense.
> >
> > Reviewed-by: Davidlohr Bueso <dave@...olabs.net>
>
> Queued and pushed, thank you all!
But an allmodconfig build complains about seq_buf_putc() being undefined,
that is, not exported. I suspect that other seq_buf_*() functions in
this patch might also be complained about.
I am dropping this for the moment. Please make it pass an allmodconfig
build so that I can pull it in again. Please see below for the commit.
Thanx, Paul
------------------------------------------------------------------------
commit a1ef9b4cff53c509f412c354c715449d7f2e159b
Author: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Date: Sat Oct 28 19:04:44 2023 +0200
refscale: Optimize process_durations()
The process_durations() function is not on a hot path, but there is
still no good reason to iterate over and over the data already in 'buf',
but this is exactly what the current use of strlen() and strcat() do.
Using a seq_buf saves some useless strcat() and the need of a temp buffer.
Data is written directly at the correct place.
Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
Reviewed-by: Davidlohr Bueso <dave@...olabs.net>
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c
index 2c2648a3ad30..861485d865ec 100644
--- a/kernel/rcu/refscale.c
+++ b/kernel/rcu/refscale.c
@@ -28,6 +28,7 @@
#include <linux/rcupdate_trace.h>
#include <linux/reboot.h>
#include <linux/sched.h>
+#include <linux/seq_buf.h>
#include <linux/spinlock.h>
#include <linux/smp.h>
#include <linux/stat.h>
@@ -890,31 +891,36 @@ static u64 process_durations(int n)
{
int i;
struct reader_task *rt;
- char buf1[64];
+ struct seq_buf s;
char *buf;
u64 sum = 0;
buf = kmalloc(800 + 64, GFP_KERNEL);
if (!buf)
return 0;
- buf[0] = 0;
+
+ seq_buf_init(&s, buf, 800 + 64);
+
sprintf(buf, "Experiment #%d (Format: <THREAD-NUM>:<Total loop time in ns>)",
exp_idx);
for (i = 0; i < n && !torture_must_stop(); i++) {
rt = &(reader_tasks[i]);
- sprintf(buf1, "%d: %llu\t", i, rt->last_duration_ns);
if (i % 5 == 0)
- strcat(buf, "\n");
- if (strlen(buf) >= 800) {
+ seq_buf_putc(&s, '\n');
+
+ if (seq_buf_used(&s) >= 800) {
+ seq_buf_terminate(&s);
pr_alert("%s", buf);
- buf[0] = 0;
+ seq_buf_clear(&s);
}
- strcat(buf, buf1);
+
+ seq_buf_printf(&s, "%d: %llu\t", i, rt->last_duration_ns);
sum += rt->last_duration_ns;
}
+ seq_buf_terminate(&s);
pr_alert("%s\n", buf);
kfree(buf);
Powered by blists - more mailing lists