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@xxxxxxxxxx> wrote: > One last semi-gentle ping. ;-) > > 1. 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. > > 2. 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
