string: strends() follow-ups

[PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 1 week, 6 days ago

A couple follow-up changes to the new strends() string helper. This
needs to go through the GPIO tree as this is where the strends()
currently is.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Bartosz Golaszewski (2):
      string: fix kerneldoc formatting in strends()
      string: use __attribute__((nonnull())) in strends()

 include/linux/string.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
---
base-commit: b32b526a0d034be69d115fae3051dda915d846ee
change-id: 20251118-strends-follow-up-740dab5871a8

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Andy Shevchenko 1 week, 6 days ago

On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> A couple follow-up changes to the new strends() string helper. This
> needs to go through the GPIO tree as this is where the strends()
> currently is.

It appears that due to some local issue my messages from the last 8
days disappeared and seemed to never be delivered. I tried to review
your v4 again and I have comments on this and patch 3. For the
strends() I proposed to get rid of strlen() calls by

  char *p;

  p = strrchr(str, suffix[0[);
  if (!p)
    return false;

  return strcmp(p, suffix) == 0;

--
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 1 week, 6 days ago

On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > A couple follow-up changes to the new strends() string helper. This
> > needs to go through the GPIO tree as this is where the strends()
> > currently is.
>
> It appears that due to some local issue my messages from the last 8
> days disappeared and seemed to never be delivered. I tried to review
> your v4 again and I have comments on this and patch 3. For the
> strends() I proposed to get rid of strlen() calls by
>
>   char *p;
>
>   p = strrchr(str, suffix[0[);
>   if (!p)
>     return false;
>
>   return strcmp(p, suffix) == 0;
>

IMO that's a bit less readable. Unless you benchmark it and show it's
faster than the current version, I'd say: let's keep the current
implementation.

Bart

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Andy Shevchenko 1 week, 6 days ago

On Tue, Nov 18, 2025 at 12:14 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

...

> > > A couple follow-up changes to the new strends() string helper. This
> > > needs to go through the GPIO tree as this is where the strends()
> > > currently is.

> > For the
> > strends() I proposed to get rid of strlen() calls by
> >
> >   char *p;
> >
> >   p = strrchr(str, suffix[0[);
> >   if (!p)
> >     return false;
> >
> >   return strcmp(p, suffix) == 0;
>
> IMO that's a bit less readable. Unless you benchmark it and show it's
> faster than the current version, I'd say: let's keep the current
> implementation.

For the static suffixes the second strlen() becomes a hardcoded value,
and I expect the benchmark will be closer to the variant I propose.
Otherwise it will be definitely faster as the strrchr() implies
partial strlen() and strcmp() is the same or even faster in my case as
here we don't do the additional calculations with the pointers. Do you
really need a benchmark for this?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 1 week, 6 days ago

On Tue, Nov 18, 2025 at 11:32 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Nov 18, 2025 at 12:14 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> ...
>
> > > > A couple follow-up changes to the new strends() string helper. This
> > > > needs to go through the GPIO tree as this is where the strends()
> > > > currently is.
>
> > > For the
> > > strends() I proposed to get rid of strlen() calls by
> > >
> > >   char *p;
> > >
> > >   p = strrchr(str, suffix[0[);
> > >   if (!p)
> > >     return false;
> > >
> > >   return strcmp(p, suffix) == 0;
> >
> > IMO that's a bit less readable. Unless you benchmark it and show it's
> > faster than the current version, I'd say: let's keep the current
> > implementation.
>
> For the static suffixes the second strlen() becomes a hardcoded value,
> and I expect the benchmark will be closer to the variant I propose.
> Otherwise it will be definitely faster as the strrchr() implies
> partial strlen() and strcmp() is the same or even faster in my case as
> here we don't do the additional calculations with the pointers. Do you
> really need a benchmark for this?
>

Ok, I don't want to load too much string-related stuff into my tree.
I'm adding it to my TODO list for the next release where I already
have an item to replace the OF-specific implementation of suffix
comparator with strends().

Bart

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Andy Shevchenko 1 week, 6 days ago

On Tue, Nov 18, 2025 at 12:43 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Tue, Nov 18, 2025 at 11:32 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Nov 18, 2025 at 12:14 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

...

> > > > > A couple follow-up changes to the new strends() string helper. This
> > > > > needs to go through the GPIO tree as this is where the strends()
> > > > > currently is.
> >
> > > > For the
> > > > strends() I proposed to get rid of strlen() calls by
> > > >
> > > >   char *p;
> > > >
> > > >   p = strrchr(str, suffix[0[);
> > > >   if (!p)
> > > >     return false;
> > > >
> > > >   return strcmp(p, suffix) == 0;
> > >
> > > IMO that's a bit less readable. Unless you benchmark it and show it's
> > > faster than the current version, I'd say: let's keep the current
> > > implementation.
> >
> > For the static suffixes the second strlen() becomes a hardcoded value,
> > and I expect the benchmark will be closer to the variant I propose.
> > Otherwise it will be definitely faster as the strrchr() implies
> > partial strlen() and strcmp() is the same or even faster in my case as
> > here we don't do the additional calculations with the pointers. Do you
> > really need a benchmark for this?
>
> Ok, I don't want to load too much string-related stuff into my tree.
> I'm adding it to my TODO list for the next release where I already
> have an item to replace the OF-specific implementation of suffix
> comparator with strends().

Okay, I have done a little benchmark (but on GLibC, a.k.a. in user
space) for both.

TL;DR: if the suffix is known (string literal) ahead, yours beats
mine, and vice versa. Since I suppose that most of the time the suffix
will be known, I think your current implementation is fine. And I
assume that the kernel implementations of the respective C functions
are on par with GLibC.

RUN 1
// static to compare with '-0c' out of 24 strings with different
endings, 23 do not match
strends1 took 0.919427 seconds to execute. (last 00-45-76-09-01-02-03-0c)
strends2 took 1.100318 seconds to execute. (last 00-45-76-09-01-02-03-0c)

// same, but the (random) suffix came from a variable, so the compiler
can't optimise that
strends1 took 1.398531 seconds to execute. (last 10-f5-06-08-04-02-03-0d)
strends2 took 1.055180 seconds to execute. (last 10-f5-06-08-04-02-03-0d)

RUN2
strends1 took 0.945234 seconds to execute. (last 00-45-76-09-01-02-03-0c)
strends2 took 1.012759 seconds to execute. (last 00-45-76-09-01-02-03-0c)
strends1 took 1.210770 seconds to execute. (last 00-45-76-09-01-02-03-04)
strends2 took 0.933389 seconds to execute. (last 00-45-76-09-01-02-03-04)

RUN3
strends1 took 0.858516 seconds to execute. (last 00-45-76-09-01-02-03-0c)
strends2 took 1.011493 seconds to execute. (last 00-45-76-09-01-02-03-0c)
strends1 took 1.221119 seconds to execute. (last 00-45-76-09-01-02-03-14)
strends2 took 0.953013 seconds to execute. (last 00-45-76-09-01-02-03-14)

Each run is 10mil over an array of 24 strings each of 24 bytes, so, I
assume cache lines are drained properly.

So, if you can see my algo beats the dynamic case well (bigger time
delta for the static comparison). If you want, it can be done both
ways (each algo for its own cases).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 1 week, 6 days ago

On Tue, Nov 18, 2025 at 12:58 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Nov 18, 2025 at 12:43 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Tue, Nov 18, 2025 at 11:32 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Tue, Nov 18, 2025 at 12:14 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
> > > > <andy.shevchenko@gmail.com> wrote:
> > > > > On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> ...
>
> > > > > > A couple follow-up changes to the new strends() string helper. This
> > > > > > needs to go through the GPIO tree as this is where the strends()
> > > > > > currently is.
> > >
> > > > > For the
> > > > > strends() I proposed to get rid of strlen() calls by
> > > > >
> > > > >   char *p;
> > > > >
> > > > >   p = strrchr(str, suffix[0[);
> > > > >   if (!p)
> > > > >     return false;
> > > > >
> > > > >   return strcmp(p, suffix) == 0;
> > > >
> > > > IMO that's a bit less readable. Unless you benchmark it and show it's
> > > > faster than the current version, I'd say: let's keep the current
> > > > implementation.
> > >
> > > For the static suffixes the second strlen() becomes a hardcoded value,
> > > and I expect the benchmark will be closer to the variant I propose.
> > > Otherwise it will be definitely faster as the strrchr() implies
> > > partial strlen() and strcmp() is the same or even faster in my case as
> > > here we don't do the additional calculations with the pointers. Do you
> > > really need a benchmark for this?
> >
> > Ok, I don't want to load too much string-related stuff into my tree.
> > I'm adding it to my TODO list for the next release where I already
> > have an item to replace the OF-specific implementation of suffix
> > comparator with strends().
>
> Okay, I have done a little benchmark (but on GLibC, a.k.a. in user
> space) for both.
>
> TL;DR: if the suffix is known (string literal) ahead, yours beats
> mine, and vice versa. Since I suppose that most of the time the suffix
> will be known, I think your current implementation is fine. And I
> assume that the kernel implementations of the respective C functions
> are on par with GLibC.
>

Thanks for taking the time to measure it. Ok, I will keep my
implementation for now then.

Bart

> RUN 1
> // static to compare with '-0c' out of 24 strings with different
> endings, 23 do not match
> strends1 took 0.919427 seconds to execute. (last 00-45-76-09-01-02-03-0c)
> strends2 took 1.100318 seconds to execute. (last 00-45-76-09-01-02-03-0c)
>
> // same, but the (random) suffix came from a variable, so the compiler
> can't optimise that
> strends1 took 1.398531 seconds to execute. (last 10-f5-06-08-04-02-03-0d)
> strends2 took 1.055180 seconds to execute. (last 10-f5-06-08-04-02-03-0d)
>
> RUN2
> strends1 took 0.945234 seconds to execute. (last 00-45-76-09-01-02-03-0c)
> strends2 took 1.012759 seconds to execute. (last 00-45-76-09-01-02-03-0c)
> strends1 took 1.210770 seconds to execute. (last 00-45-76-09-01-02-03-04)
> strends2 took 0.933389 seconds to execute. (last 00-45-76-09-01-02-03-04)
>
> RUN3
> strends1 took 0.858516 seconds to execute. (last 00-45-76-09-01-02-03-0c)
> strends2 took 1.011493 seconds to execute. (last 00-45-76-09-01-02-03-0c)
> strends1 took 1.221119 seconds to execute. (last 00-45-76-09-01-02-03-14)
> strends2 took 0.953013 seconds to execute. (last 00-45-76-09-01-02-03-14)
>
> Each run is 10mil over an array of 24 strings each of 24 bytes, so, I
> assume cache lines are drained properly.
>
> So, if you can see my algo beats the dynamic case well (bigger time
> delta for the static comparison). If you want, it can be done both
> ways (each algo for its own cases).
>

Re: (subset) [PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 6 days, 16 hours ago

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Tue, 18 Nov 2025 11:04:02 +0100, Bartosz Golaszewski wrote:
> A couple follow-up changes to the new strends() string helper. This
> needs to go through the GPIO tree as this is where the strends()
> currently is.
> 
> 

Applied, thanks!

[2/2] string: use __attribute__((nonnull())) in strends()
      https://git.kernel.org/brgl/linux/c/194832dcb13b0d02fce0df887235b7e6d1ef0121

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Re: (subset) [PATCH 0/2] string: strends() follow-ups

Posted by Bartosz Golaszewski 1 week, 4 days ago

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Tue, 18 Nov 2025 11:04:02 +0100, Bartosz Golaszewski wrote:
> A couple follow-up changes to the new strends() string helper. This
> needs to go through the GPIO tree as this is where the strends()
> currently is.
> 
> 

Queuing this one to fix a warning in next. The other one can wait
for reviews.

[1/2] string: fix kerneldoc formatting in strends()
      https://git.kernel.org/brgl/linux/c/6f87b41303d3c4280a57b4f7360022a0951b43dd

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>