[PATCH] eal/unix: optimize thread creation with glibc

[David Marchand]

On Sat, Nov 2, 2024 at 8:58 PM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> On Sat,  2 Nov 2024 11:08:39 +0100
> David Marchand <david.marchand at redhat.com> wrote:
>
> > Setting the cpu affinity of the child thread from the parent thread is
> > racy when using pthread_setaffinity_np, as the child thread may start
> > running and initialize before affinity is set.
> >
> > On the other hand, setting the cpu affinity from the child thread itself
> > may fail, so the parent thread waits for the child thread to report
> > whether this call succeeded.
> >
> > This synchronisation point resulted in a significant slow down of
> > rte_thread_create() (as seen in the lcores_autotest unit tests, in OBS
> > for some ARM systems).
> >
> > Another option for setting cpu affinity is to use the not portable
> > pthread_attr_setaffinity_np, but it is not available with musl.
> > Assume availability by relying on __USE_GNU that is not set with musl.
> >
> > Fixes: b28c6196b132 ("eal/unix: fix thread creation")
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand at redhat.com>
> > ---
>
> Seems like a reasonable way forward but not sure.
>
> What about FreeBSD (which shares this code)?

I did not investigate FreeBSD.
Either we find a "good" #define, or we could add some detection in
meson (probably the best option).


>
> Looking inside glibc, what it does is have the parent call sched_setaffinty()
> after the clone system call with the thread id. So using attributes is
> just as racy as the original code.

It there was such a race in the glibc, I would call it a bug.

Afaiu, the parent calls sched_setaffinity while holding a lock on the
child thread, see CREATE THREAD NOTES: and stopped_start.


-- 
David Marchand