public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Chris von Recklinghausen <crecklin@redhat.com>,
	Jason Baron <jbaron@akamai.com>, Scott Wood <swood@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Clark Williams <williams@redhat.com>,
	x86@kernel.org
Subject: Re: [PATCH V3 0/9] x86/jump_label: Bound IPIs sent when updating a static key
Date: Fri, 19 Apr 2019 21:01:12 +0200	[thread overview]
Message-ID: <20190419190112.GA95540@gmail.com> (raw)
In-Reply-To: <cover.1545228276.git.bristot@redhat.com>


* Daniel Bristot de Oliveira <bristot@redhat.com> wrote:

> Considering that, in this test case, we are saving the handling of 53 IPIs,
> that takes more than these 135 ns, it seems to be a meager price to be paid.
> Moreover, the test case was forcing the hit of the int3, in practice, it
> does not take that often. While the IPI takes place on all CPUs, hitting
> the int3 handler or not!
> 
> For instance, in an isolated CPU with a process running in user-space
> (nohz_full use-case), the chances of hitting the int3 handler is barely zero,
> while there is no way to avoid the IPIs. By bounding the IPIs, we are improving
> this scenario a lot.
> 
> Changes from v2:
>   - Switch the order of patches 8 and 9 (Steven Rostedt)
>   - Fallback in the case of failure in the batch mode (Steven Rostedt)
>   - Fix a pointer in patch 7 (Steven Rostedt)
>   - Adjust the commit log of the patch 1 (Borislav Petkov)
>   - Adjust the commit log of the patch 3 (Jiri Kosina/Thomas Gleixner)
> Changes from v1:
>   - Split the patch in jump-label/x86-jump-label/alternative (Jason Baron)
>   - Use bserach in the int3 handler (Steven Rostedt)
>   - Use a pre-allocated page to store the vector (Jason/Steven)
>   - Do performance tests in the int3 handler (peterz)
>
> Daniel Bristot de Oliveira (9):
>   jump_label: Add for_each_label_entry helper
>   jump_label: Add the jump_label_can_update_check() helper
>   x86/jump_label: Move checking code away from __jump_label_transform()
>   x86/jump_label: Add __jump_label_set_jump_code() helper
>   x86/alternative: Split text_poke_bp() into tree steps
>   jump_label: Sort entries of the same key by the code
>   x86/alternative: Batch of patch operations
>   jump_label: Batch updates if arch supports it
>   x86/jump_label: Batch jump label updates
> 
>  arch/x86/include/asm/jump_label.h    |   2 +
>  arch/x86/include/asm/text-patching.h |  15 +++
>  arch/x86/kernel/alternative.c        | 140 ++++++++++++++++++---
>  arch/x86/kernel/jump_label.c         | 174 ++++++++++++++++++++++-----
>  include/linux/jump_label.h           |   6 +
>  kernel/jump_label.c                  |  73 +++++++++--
>  6 files changed, 359 insertions(+), 51 deletions(-)

Note that I've applied these to tip:WIP.x86/alternatives to help move it 
along and help with testing, but before this can go upstream review 
feedback from PeterZ needs to be addressed.

Please send the latest series (v3, v4, etc.) with full patches to make it 
easy to review from scratch to everyone - I'll reshuffle the WIP branch 
accordingly. These are not stable SHA1's yet.

Thanks,

	Ingo

      parent reply	other threads:[~2019-04-19 19:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 10:27 [PATCH V3 0/9] x86/jump_label: Bound IPIs sent when updating a static key Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 1/9] jump_label: Add for_each_label_entry helper Daniel Bristot de Oliveira
2019-04-19 18:36   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 2/9] jump_label: Add the jump_label_can_update_check() helper Daniel Bristot de Oliveira
2019-04-19 18:37   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 3/9] x86/jump_label: Move checking code away from __jump_label_transform() Daniel Bristot de Oliveira
2019-04-19 18:38   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 4/9] x86/jump_label: Add __jump_label_set_jump_code() helper Daniel Bristot de Oliveira
2019-04-19 18:38   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 5/9] x86/alternative: Split text_poke_bp() into tree steps Daniel Bristot de Oliveira
2019-04-19 18:39   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 6/9] jump_label: Sort entries of the same key by the code Daniel Bristot de Oliveira
2019-04-19 18:40   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 7/9] x86/alternative: Batch of patch operations Daniel Bristot de Oliveira
2019-01-23  5:15   ` Masami Hiramatsu
2019-01-26 11:52     ` Daniel Bristot de Oliveira
2019-01-28 13:52       ` Masami Hiramatsu
2019-02-01 12:49         ` Daniel Bristot de Oliveira
2019-02-01 14:47           ` Masami Hiramatsu
2019-02-01 15:51             ` Daniel Bristot de Oliveira
2019-04-19 18:41   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 8/9] jump_label: Batch updates if arch supports it Daniel Bristot de Oliveira
2019-04-19 18:42   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2018-12-21 10:27 ` [PATCH V3 9/9] x86/jump_label: Batch jump label updates Daniel Bristot de Oliveira
2019-04-19 18:42   ` [tip:x86/alternatives] " tip-bot for Daniel Bristot de Oliveira
2019-01-21 12:52 ` [PATCH V3 0/9] x86/jump_label: Bound IPIs sent when updating a static key Daniel Bristot de Oliveira
2019-04-19 19:01 ` Ingo Molnar [this message]

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=20190419190112.GA95540@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=bristot@redhat.com \
    --cc=crecklin@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jbaron@akamai.com \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=swood@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    --cc=x86@kernel.org \
    /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