All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: ira.weiny@intel.com, Rik van Riel <riel@surriel.com>,
	Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry
Date: Fri, 5 Aug 2022 11:47:10 -0700	[thread overview]
Message-ID: <5d62c1d0-7425-d5bb-ecb5-1dc3b4d7d245@intel.com> (raw)
In-Reply-To: <20220805173009.3128098-6-ira.weiny@intel.com>

On 8/5/22 10:30, ira.weiny@intel.com wrote:
> +static inline void arch_save_aux_pt_regs(struct pt_regs *regs)
> +{
> +	struct pt_regs_auxiliary *aux_pt_regs = &to_extended_pt_regs(regs)->aux;
> +
> +	aux_pt_regs->cpu = raw_smp_processor_id();
> +}

This is in a fast path that all interrupt and exception entry uses.  So,
I was curious what the overhead is.

Code generation in irqentry_enter() gets a _bit_ more complicated
because arch_save_aux_pt_regs() has to be done on the way out of the
function and the compiler can't (for instance) do a

	mov    $0x1,%eax
	ret

to return.  But, the gist of the change is still only two instructions
that read a pretty hot, read-only per-cpu cacheline:

	mov    %gs:0x7e21fa4a(%rip),%eax        # 15a38 <cpu_number>
	mov    %eax,-0x8(%rbx)

That doesn't seem too bad.

  parent reply	other threads:[~2022-08-05 18:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05 17:30 [RFC PATCH 0/5] Print CPU at segfault time ira.weiny
2022-08-05 17:30 ` [RFC PATCH 1/5] entry: Pass pt_regs to irqentry_exit_cond_resched() ira.weiny
2022-08-05 18:33   ` Rik van Riel
2022-08-08 10:38   ` Borislav Petkov
2022-08-08 17:34     ` Ira Weiny
2022-08-08 17:38       ` Borislav Petkov
2022-08-08 17:43         ` Dave Hansen
2022-08-08 17:52           ` Borislav Petkov
2022-08-09 23:18     ` Thomas Gleixner
2022-08-10  7:25       ` Thomas Gleixner
2022-08-05 17:30 ` [RFC PATCH 2/5] entry: Add calls for save/restore auxiliary pt_regs ira.weiny
2022-08-05 18:34   ` Rik van Riel
2022-08-09 12:05   ` Borislav Petkov
2022-08-09 18:38     ` Ira Weiny
2022-08-09 18:49       ` Borislav Petkov
2022-08-09 21:14         ` Thomas Gleixner
2022-08-09 21:38           ` Borislav Petkov
2022-08-09 22:33             ` Ira Weiny
2022-08-09 21:49         ` Ira Weiny
2022-08-09 23:53           ` Thomas Gleixner
2022-08-05 17:30 ` [RFC PATCH 3/5] x86/entry: Add auxiliary pt_regs space ira.weiny
2022-08-05 18:45   ` Rik van Riel
2022-08-05 17:30 ` [RFC PATCH 4/5] x86,mm: print likely CPU at segfault time ira.weiny
2022-08-05 17:30 ` [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry ira.weiny
2022-08-05 18:46   ` Rik van Riel
2022-08-05 18:47   ` Dave Hansen [this message]
2022-08-06  9:01     ` Ingo Molnar
2022-08-06  9:11       ` Borislav Petkov
2022-08-07 10:02         ` Ingo Molnar
2022-08-07 10:35           ` Borislav Petkov
2022-08-07 20:02             ` Ira Weiny
2022-08-08 11:03               ` Ingo Molnar
2022-08-08 12:01                 ` Borislav Petkov
2022-08-09 20:06                   ` Thomas Gleixner
2022-08-08 16:16                 ` Dave Hansen
2022-08-08 17:24                   ` Rik van Riel
2022-08-09 21:19                   ` Andy Lutomirski

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=5d62c1d0-7425-d5bb-ecb5-1dc3b4d7d245@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=ira.weiny@intel.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@surriel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.