On Thu, Oct 31, 2024 at 9:46 PM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Thu, 31 Oct 2024 14:05:16 +0000 > Luca Boccassi <luca.bocca...@gmail.com> wrote: > > > On Thu, 31 Oct 2024 at 13:04, David Marchand <david.march...@redhat.com> > > wrote: > > > > > > On Thu, Oct 31, 2024 at 1:58 PM Luca Boccassi <luca.bocca...@gmail.com> > > > wrote: > > > > > > > > On Thu, 31 Oct 2024 at 12:52, David Marchand > > > > <david.march...@redhat.com> wrote: > > > > > > > > > > On Thu, Oct 31, 2024 at 1:47 PM David Marchand > > > > > <david.march...@redhat.com> wrote: > > > > > > Could you share a backtrace when hitting this deadlock? > > > > > > > > > > If the backtrace is not possible, running with > > > > > --log-level=lib.eal:debug may help. > > > > > > > > I cannot get backtraces. This runs via "meson test", how can that > > > > option be passed in? > > > > > > # meson test -C build-debian --suite fast-tests --verbose -t 5 > > > --test-args=--log-level=lib.eal:debug > > > > https://paste.debian.net/1334095/ > > Could not repro this on Raspberry Pi 5. Main branch builds and runs
There is no deadlock at play, as far as I can see. The mentionned commit slowed down thread instantiation (a lot, from what the timestamps seen in the paste link). The exact reason is not entirely clear to me, but it forced the thread creating children threads to wait for them to start running. Reverting this commit enhances the situation, but reintroduce a double free (if set affinity of the created thread fails, both the parent and the created thread will free ctx). I sent a patch, reintroducing use of pthread_attr_setaffinity_np like Tyler had first proposed. Let's see what the CI think of this. -- David Marchand
