Le Thu, Apr 06, 2023 at 04:12:04PM +0200, Marco Elver a écrit :
On Thu, 16 Mar 2023 at 13:31, Marco Elver elver@google.com wrote: One last semi-gentle ping. ;-)
- We're seeing that in some applications that use POSIX timers
heavily, but where the main thread is mostly idle, the main thread receives a disproportional amount of the signals along with being woken up constantly. This is bad, because the main thread usually waits with the help of a futex or really long sleeps. Now the main thread will steal time (to go back to sleep) from another thread that could have instead just proceeded with whatever it was doing.
- Delivering signals to random threads is currently way too
expensive. We need to resort to this crazy algorithm: 1) receive timer signal, 2) check if main thread, 3) if main thread (which is likely), pick a random thread and do tgkill. To find a random thread, iterate /proc/self/task, but that's just abysmal for various reasons. Other alternatives, like inherited task clock perf events are too expensive as soon as we need to enable/disable the timers (does IPIs), and maintaining O(#threads) timers is just as horrible.
This patch solves both the above issues.
We acknowledge the unfortunate situation of attributing this patch to one clear subsystem and owner: it straddles into signal delivery and POSIX timers territory, and perhaps some scheduling. The patch itself only touches kernel/signal.c.
If anyone has serious objections, please shout (soon'ish). Given the patch has been reviewed by Oleg, and scrutinized by Dmitry and myself, presumably we need to find a tree that currently takes kernel/signal.c patches?
Thanks!
Thanks for the reminder!
In the very unlikely case Thomas ignores this before the next merge window, I'll tentatively do a pull request to Linus.
Thanks.
-- Marco