On Sat, Nov 2, 2024 at 8:58 PM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Sat, 2 Nov 2024 11:08:39 +0100 > David Marchand <david.march...@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: sta...@dpdk.org > > > > Signed-off-by: David Marchand <david.march...@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