> Note that the RCU thread is expected to sit most of the time doing > nothing, so I don't think this matters.
Agreed. > Zhengui's theory that notify_me doesn't work properly on ARM is more > promising, but he couldn't provide a clear explanation of why he thought > notify_me is involved. In particular, I would have expected notify_me to > be wrong if the qemu_poll_ns call came from aio_ctx_dispatch, for example: > > > glib_pollfds_fill > g_main_context_prepare > aio_ctx_prepare > atomic_or(&ctx->notify_me, 1) > qemu_poll_ns > glib_pollfds_poll > g_main_context_check > aio_ctx_check > atomic_and(&ctx->notify_me, ~1) > g_main_context_dispatch > aio_ctx_dispatch > /* do something for event */ > qemu_poll_ns > Yep, will focus there. > > Can you place somewhere your util/async.o object file for me to look at it? Sure! https://send.firefox.com/download/45c26bbe1075eea1/#ZD_e_96imPG2QuDqaX-jhg Note: this async.o has value as int, EV_BUSY as 3, aborts if any errno in qemu_futex() and uses &ev->value as 1st argument to wake/wait (as in https://pastebin.ubuntu.com/p/xk8D6H6kgM/). > > You could change it to 3, but it has to have all the bits in EV_FREE > (see atomic_or(&ev->value, EV_FREE) in qemu_event_reset). > > You could also change it to -1u, but I don't see a particular need to do so. > Yep, it was a dead end on my side. >> - Should qemu_event_set() check return code from >> qemu_futex_wake()->qemu_futex()->syscall() in order to know if ANY >> waiter was ever woken up ? Maybe even loop until at least 1 is awaken ? > > Why would it need to do so? > No need, just realized after I saw no tasks waking that thread up. Like you said, ctx->notify_me seems more promising, will give it a try.
