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.
Signed-off-by: Christophe JAILLET <[email protected]>
---
kernel/rcu/refscale.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
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);
--
2.34.1
On Sat, 28 Oct 2023 19:04:44 +0200
Christophe JAILLET <[email protected]> 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.
>
Agreed.
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> kernel/rcu/refscale.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> 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');
I was confused here thinking it was originally adding a '\n' to buf1 on
i % 5, but it's adding it to buf!
Yeah, using seq_buf is much less confusing and then less error prone.
Reviewed-by: Steven Rostedt (Google) <[email protected]>
-- Steve
> +
> + 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);
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 <[email protected]>
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 <[email protected]>
Queued and pushed, thank you all!
Thanx, Paul
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 <[email protected]>
>
> 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 <[email protected]>
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 <[email protected]>
Reviewed-by: Steven Rostedt (Google) <[email protected]>
Reviewed-by: Davidlohr Bueso <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
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);
Le 31/10/2023 à 23:47, Paul E. McKenney a écrit :
> 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 <[email protected]>
>>
>> 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
>
Ouch!
seq_buf_init(), seq_buf_terminate(), seq_buf_clear() are inlined
functions in a .h file, so shouldn't be a problem.
seq_buf_printf() is exported, but seq_buf_putc() is not!
Really odd to me.
Kees Cook (added in cc) suggests to use this API (see [1]) to avoid some
potential issues and ease the management of NULL terminated strings in
buffers. (#LinuxHardening).
I'll propose to add the missing EXPORT_SYMBOL_GPL.
CJ
[1]: https://lore.kernel.org/all/202310241629.0A4206316F@keescook/
On Wed, Nov 01, 2023 at 08:41:39AM +0100, Christophe JAILLET wrote:
> Le 31/10/2023 ? 23:47, Paul E. McKenney a ?crit?:
> > 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 <[email protected]>
> > >
> > > 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.
>
> Ouch!
Believe me, I know that feeling! ;-)
> seq_buf_init(), seq_buf_terminate(), seq_buf_clear() are inlined functions
> in a .h file, so shouldn't be a problem.
>
> seq_buf_printf() is exported, but seq_buf_putc() is not!
> Really odd to me.
>
> Kees Cook (added in cc) suggests to use this API (see [1]) to avoid some
> potential issues and ease the management of NULL terminated strings in
> buffers. (#LinuxHardening).
>
> I'll propose to add the missing EXPORT_SYMBOL_GPL.
Very good, looking forward to seeing the result.
Thanx, Paul
> CJ
>
> [1]: https://lore.kernel.org/all/202310241629.0A4206316F@keescook/
>