All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [GIT pull] x86 mpx support for 3.19
Date: Thu, 11 Dec 2014 07:19:35 +0100	[thread overview]
Message-ID: <20141211061935.GA5059@gmail.com> (raw)
In-Reply-To: <5488AF8D.5070702@linux.intel.com>


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

> @@ -1575,6 +1571,27 @@ config X86_SMAP
>  
>  	  If unsure, say Y.
>  
> +config X86_INTEL_MPX
> +	prompt "Intel MPX (Memory Protection Extensions)" if EXPERT

I think the 'if EXPERT' needs to be dropped.

> +	def_bool y
> +	depends on CPU_SUP_INTEL

On the one hand, the 'def_bool y' might be acceptable, if we 
think of MPX as X32 or SECCOMP: ABI extensions that are only 
really useful if all distros enable it.

On the other hand, unlike x32 and seccomp, MPX increases data 
structure size and adds a few instructions to common, non-MPX 
code paths, so the cost isn't just kernel image size.

Linus, what's your preference?

> +	  Enabling this option will make the kernel larger and
> +	  slightly increase the size of some kernel data
> +	  structures.

And will add a few branches to critical code paths, right?

It would be nice to give some numeric data in such cases, by what 
percentage does MPX support increase the x86_64 defconfig kernel 
for example? By how much does it increase data structure size? 
Make costs and benefits transparent and most people will chose 
wisely, or at least well informed.

Thanks,

	Ingo

  parent reply	other threads:[~2014-12-11  6:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 14:08 [GIT pull] x86 mpx support for 3.19 Thomas Gleixner
2014-12-10 19:05 ` Linus Torvalds
2014-12-10 19:41   ` Dave Hansen
2014-12-10 19:49     ` Linus Torvalds
2014-12-10 20:39       ` Dave Hansen
2014-12-10 20:49         ` Linus Torvalds
2014-12-12 16:40           ` H. Peter Anvin
2014-12-11  6:19         ` Ingo Molnar [this message]
2014-12-11 22:02           ` Dave Hansen
2014-12-12  8:31             ` Ingo Molnar
2014-12-12 12:30             ` Pavel Machek
2014-12-12 15:47               ` Dave Hansen
2014-12-12 17:21                 ` Pavel Machek
2014-12-10 19:49   ` Dave Hansen
2014-12-11  2:14 ` Eric W. Biederman
2014-12-11  2:30   ` Dave Hansen

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=20141211061935.GA5059@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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.