From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] signal: optimise signal_pending()
Date: Mon, 17 May 2021 12:22:13 -0500 [thread overview]
Message-ID: <m1o8d95l8a.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <a068c25c4c08aa8dbc1141a77614711f80f74b65.1621245687.git.asml.silence@gmail.com> (Pavel Begunkov's message of "Mon, 17 May 2021 11:18:07 +0100")
Pavel Begunkov <asml.silence@gmail.com> writes:
> Optimise signal_pending() by checking both TIF_SIGPENDING and
> TIF_NOTIFY_SIGNAL at once. Saves quite a bit of generated instructions,
> e.g. sheds 240B from io_uring alone, some including ones in hot paths.
>
> text data bss dec hex filename
> 84087 12414 8 96509 178fd ./fs/io_uring.o
> 83847 12414 8 96269 1780d ./fs/io_uring.o
I believe the atomic test_bit is pretty fundamental, especially with
it's implied barriers. I believe you are optimizing out the code
that will makes signal_pending work in a loop.
I have tried looking and I really don't understand why TIF_NOTIFY_SIGNAL
was added. Perhaps instead of trying to optimize the test, you should
optimize by combining TIF_NOTIFY_SIGNAL with TIF_SIGPENDING.
Perhaps set_notify_signal could be optimized to set both. I think I
only see 4 calls in the tree.
> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
> ---
>
> Suggestions on how to make it less disruptive to abstractions are most
> welcome, as even the one below fails to generated anything sane because
> of test_bit()
>
> return unlikely(test_ti_thread_flag(ti, TIF_SIGPENDING) |
> test_ti_thread_flag(ti, TIF_SIGPENDING));
>
> include/linux/sched/signal.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> index 3f6a0fcaa10c..97e1963a13fc 100644
> --- a/include/linux/sched/signal.h
> +++ b/include/linux/sched/signal.h
> @@ -361,14 +361,14 @@ static inline int task_sigpending(struct task_struct *p)
>
> static inline int signal_pending(struct task_struct *p)
> {
> + struct thread_info *ti = task_thread_info(p);
> +
> /*
> * TIF_NOTIFY_SIGNAL isn't really a signal, but it requires the same
> * behavior in terms of ensuring that we break out of wait loops
> * so that notify signal callbacks can be processed.
> */
> - if (unlikely(test_tsk_thread_flag(p, TIF_NOTIFY_SIGNAL)))
> - return 1;
> - return task_sigpending(p);
> + return unlikely(ti->flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL));
> }
>
> static inline int __fatal_signal_pending(struct task_struct *p)
next prev parent reply other threads:[~2021-05-17 17:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 10:18 [PATCH] signal: optimise signal_pending() Pavel Begunkov
2021-05-17 17:22 ` Eric W. Biederman [this message]
2021-05-17 22:14 ` Pavel Begunkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1o8d95l8a.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox