linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC][PATCH 4/4] x86, mpx: context-switch new MPX address size MSR
Date: Fri, 27 Jan 2017 09:31:22 +0100	[thread overview]
Message-ID: <20170127083122.GC25162@gmail.com> (raw)
In-Reply-To: <20170126224010.3534C154@viggo.jf.intel.com>


* Dave Hansen <dave.hansen@linux.intel.com> wrote:

> + * The MPX tables change sizes based on the size of the virtual
> + * (aka. linear) address space.  There is an MSR to tell the CPU
> + * whether we want the legacy-style ones or the larger ones when
> + * we are running with an eXtended virtual address space.
> + */
> +static void switch_mawa(struct mm_struct *prev, struct mm_struct *next)
> +{
> +	/*
> +	 * Note: there is one and only one bit in use in the MSR
> +	 * at this time, so we do not have to be concerned with
> +	 * preseving any of the other bits.  Just write 0 or 1.
> +	 */
> +	unsigned IA32_MPX_LAX_ENABLE_MASK = 0x00000001;
> +
> +	if (!cpu_feature_enabled(X86_FEATURE_MPX))
> +		return;
> +	/*
> +	 * FIXME: do we want a check here for the 5-level paging
> +	 * CR4 bit or CPUID bit, or is the mawa check below OK?
> +	 * It's not obvious what would be the fastest or if it
> +	 * matters.
> +	 */
> +
> +	/*
> +	 * Avoid the relatively costly MSR if we are not changing
> +	 * MAWA state.  All processes not using MPX will have a
> +	 * mpx_mawa_shift()=0, so we do not need to check
> +	 * separately for whether MPX management is enabled.
> +	 */
> +	if (mpx_mawa_shift(prev) == mpx_mawa_shift(next))
> +		return;

Please stop the senseless looking wrappery - if the field is name sensibly then it 
can be accessed directly through mm_struct.

> +
> +	if (mpx_mawa_shift(next)) {
> +		wrmsr(MSR_IA32_MPX_LAX, IA32_MPX_LAX_ENABLE_MASK, 0x0);
> +	} else {
> +		/* clear the enable bit: */
> +		wrmsr(MSR_IA32_MPX_LAX, 0x0, 0x0);
> +	}
> +}
> +
>  void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
>  			struct task_struct *tsk)
>  {
> @@ -136,6 +177,7 @@ void switch_mm_irqs_off(struct mm_struct
>  		/* Load per-mm CR4 state */
>  		load_mm_cr4(next);
>  
> +		switch_mawa(prev, next);

This implementation adds about 4-5 unnecessary instructions to the context 
switching hot path of every non-MPX task, even on non-MPX hardware.

Please make sure that this is something like:

	if (unlikely(prev->mpx_msr_val != next->mpx_msr_val))
		switch_mpx(prev, next);

... which reduces the hot path overhead to something like 2 instruction (if we are 
lucky).

This can be put into switch_mpx() and can be inlined - just make sure that on a 
defconfig the generated machine code is sane.

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-01-27  8:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 22:40 [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA) Dave Hansen
2017-01-26 22:40 ` [RFC][PATCH 1/4] x86, mpx: introduce per-mm MPX table size tracking Dave Hansen
2017-01-27  8:26   ` Ingo Molnar
2017-01-26 22:40 ` [RFC][PATCH 2/4] x86, mpx: update MPX to grok larger bounds tables Dave Hansen
2017-01-26 22:40 ` [RFC][PATCH 3/4] x86, mpx: extend MPX prctl() to pass in size of bounds directory Dave Hansen
2017-01-26 22:40 ` [RFC][PATCH 4/4] x86, mpx: context-switch new MPX address size MSR Dave Hansen
2017-01-27  8:31   ` Ingo Molnar [this message]
2017-01-27  8:16 ` [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA) Ingo Molnar

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=20170127083122.GC25162@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tglx@linutronix.de \
    --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