Re: [PATCH v2 1/2] perf test workload noploop: Name the noploop process

[Namhyung Kim <namhyung@kernel.org>]

On Mon, Jun 23, 2025 at 12:41:09PM -0700, Ian Rogers wrote:
> On Mon, Jun 23, 2025 at 12:19 PM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > On Mon, Jun 23, 2025 at 11:14:47AM -0700, Namhyung Kim wrote:
> > > On Mon, Jun 23, 2025 at 11:05:41AM -0700, Ian Rogers wrote:
> > > > On Mon, Jun 23, 2025 at 10:45 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > > > On Mon, Jun 23, 2025 at 08:12:47AM -0700, Ian Rogers wrote:
> > > > > > On Fri, Jun 20, 2025 at 12:36 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > > > > > > I'm afraid it'd introduce a build failure on musl.  Please see
> >
> > > > > > > https://lore.kernel.org/linux-perf-users/20250611092542.F4ooE2FL@linutronix.de/
> >
> > > > > > > I think <sys/prctl.h> would be enough.
> >
> > > > > > we could do that but in the glibc man page it says:
> > > > > > https://man7.org/linux/man-pages/man2/prctl.2.html
> > > > > > ```
> > > > > > #include <linux/prctl.h>  /* Definition of PR_* constants */
> > > > > > #include <sys/prctl.h>
> > > > > > ```
> >
> > > > > > It'd be nice to think musl was slowly getting fixed. I notice we're
> >
> > > > > Sebastian reported on the musl libc, its maintainer replied:
> >
> > > > > https://www.openwall.com/lists/musl/2025/06/12/11
> >
> > > > Ugh. I'm not sure how we're expected to resolve this and have glibc
> > > > and musl be happy without basically not trusting libc.
> >
> > > Maybe pthread_setname_np()?  It seems musl also implemented it.
> >
> > ⬢ [acme@toolbx perf-tools-next]$ git diff
> > diff --git a/tools/perf/tests/workloads/noploop.c b/tools/perf/tests/workloads/noploop.c
> > index 8b954d4660833a2f..656e472e618822a3 100644
> > --- a/tools/perf/tests/workloads/noploop.c
> > +++ b/tools/perf/tests/workloads/noploop.c
> > @@ -1,9 +1,8 @@
> >  /* SPDX-License-Identifier: GPL-2.0 */
> > +#include <pthread.h>
> >  #include <stdlib.h>
> >  #include <signal.h>
> >  #include <unistd.h>
> > -#include <linux/prctl.h>
> > -#include <sys/prctl.h>
> >  #include <linux/compiler.h>
> >  #include "../tests.h"
> >
> > @@ -18,7 +17,7 @@ static int noploop(int argc, const char **argv)
> >  {
> >         int sec = 1;
> >
> > -       prctl(PR_SET_NAME, "perf-noploop");
> > +       pthread_setname_np(pthread_self(), "perf-noploop");
> >         if (argc > 0)
> >                 sec = atoi(argv[0]);
> >
> > ⬢ [acme@toolbx perf-tools-next]$
> >
> > ⬢ [acme@toolbx perf-tools-next]$ perf test -w noploop &
> > [1] 1179763
> > ⬢ [acme@toolbx perf-tools-next]$ ps
> >     PID TTY          TIME CMD
> >    3935 pts/1    00:00:00 bash
> >    4053 pts/1    00:00:00 toolbox
> >    4222 pts/1    00:00:28 podman
> >  971900 pts/1    00:00:00 bash
> > 1100453 pts/1    00:00:00 tail
> > 1160346 pts/1    00:00:00 bash
> > 1179763 pts/1    00:00:00 perf-noploop
> > 1179765 pts/1    00:00:00 ps
> > ⬢ [acme@toolbx perf-tools-next]$
> >
> > And then on one of the Alpine Linux containers:
> >
> > make: Leaving directory '/tmp/perf-6.16.0-rc3/tools/perf'
> > /tmp/perf-6.16.0-rc3 $ cat /etc/os-release
> > NAME="Alpine Linux"
> > ID=alpine
> > VERSION_ID=3.18.12
> > PRETTY_NAME="Alpine Linux v3.18"
> > HOME_URL="https://alpinelinux.org/"
> > BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
> > /tmp/perf-6.16.0-rc3 $ tools/perf/perf test -w noploop &
> > /tmp/perf-6.16.0-rc3 $ ps
> > PID   USER     TIME  COMMAND
> >     1 toolsbui  0:00 /bin/sh
> >  5693 toolsbui  0:00 {perf-noploop} tools/perf/perf test -w noploop
> >  5694 toolsbui  0:00 ps
> > /tmp/perf-6.16.0-rc3 $
> > [1]+  Done                       tools/perf/perf test -w noploop
> > /tmp/perf-6.16.0-rc3
> >
> > There are more direct use of prctl() to set the name in tools/perf/,
> > using pthread_setname_np() seems cleaner :-)
> 
> Yeah, I wanted to set the program name rather than a thread name for
> the sake of seeing the process name in ps - hence reaching for prctl.
> PR_SET_NAME is documented as setting the thread name and so no
> difference to pthread_setname_np. It's still frustrating to get bogged
> down in working around musl when typing the literal code from the
> prctl man page. Do you need me to re-send the patch?

Yes please.  And address comments in the patch 2 as well.

Thanks,
Namhyung