LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: x86-ml <x86@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	lkml <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [GIT PULL] x86/alternatives padding
Date: Wed, 4 Mar 2015 08:32:21 +0100	[thread overview]
Message-ID: <20150304073221.GD22014@gmail.com> (raw)
In-Reply-To: <20150303170632.GE25768@pd.tnic>


* Borislav Petkov <bp@alien8.de> wrote:

> Hi guys,
> 
> so this one has been long in the making and has been passing testing
> on a bunch of boxes and bitness here so maybe we should try to put it
> into the wider tip mix and see what happens. If all is well, great, if
> there's trouble which I haven't managed to trigger in my testing, we can
> remove it from tip/master until all issues are fixed.
> 
> Btw, the last three patches are adjusting and improving perf bench a
> little as it includes memcpy/memset_64.S directly and this patchset
> breaks it with the changes otherwise.
> 
> Please pull,
> thanks.
> 
> ---
> The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
> 
>   Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/alternatives_padding
> 
> for you to fetch changes up to dfecb95cdfeaf7872d83a96bec3a606e9cd95c8d:
> 
>   perf/bench: Add -r all so that you can run all mem* routines (2015-03-03 18:01:58 +0100)
> 
> ----------------------------------------------------------------
> A more involved rework of the alternatives framework to be able to
> pad instructions and thus make using the alternatives macros more
> straightforward and without having to figure out old and new instruction
> sizes but have the toolchain figure that out for us.
> 
> Furthermore, it optimizes JMPs used so that fetch and decode can be
> relieved with smaller versions of the JMPs, where possible.
> 
> Some stats:
> 
> x86_64 defconfig:
> 
> Alternatives sites total:               2478
> Total padding added (in Bytes):         6051

Just curious: did the kernel image size change before/after these 
changes? I.e. was any of the existing alternative instructions using 
sites coded sub-optimally, with a larger maximum instruction size 
allocated than strictly needed?

At least some of your improvements made things more optimal - 
wondering at the total win, beyond the significant maintainability win 
that is.

> The padding is currently done for:
> 
> X86_FEATURE_ALWAYS
> X86_FEATURE_ERMS
> X86_FEATURE_LFENCE_RDTSC
> X86_FEATURE_MFENCE_RDTSC
> X86_FEATURE_SMAP
> 
> This is with the latest version of the patchset. Of course, on each
> machine the alternatives sites actually being patched are a proper
> subset of the total number.
> 
> ----------------------------------------------------------------
> Borislav Petkov (18):
>       x86/lib/copy_user_64.S: Remove FIX_ALIGNMENT define
>       x86/alternatives: Cleanup DPRINTK macro
>       x86/alternatives: Add instruction padding
>       x86/alternatives: Make JMPs more robust
>       x86/alternatives: Use optimized NOPs for padding
>       x86/lib/copy_page_64.S: Use generic ALTERNATIVE macro
>       x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2
>       x86/smap: Use ALTERNATIVE macro
>       x86/entry_32: Convert X86_INVD_BUG to ALTERNATIVE macro
>       x86/lib/clear_page_64.S: Convert to ALTERNATIVE_2 macro
>       x86/asm: Use alternative_2() in rdtsc_barrier()
>       x86/asm: Cleanup prefetch primitives
>       x86/lib/memset_64.S: Convert to ALTERNATIVE_2 macro
>       x86/lib/memmove_64.S: Convert memmove() to ALTERNATIVE macro
>       x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro
>       perf/bench: Fix mem* routines usage after alternatives change
>       perf/bench: Carve out mem routine benchmarking
>       perf/bench: Add -r all so that you can run all mem* routines
> 
>  arch/x86/include/asm/alternative-asm.h        |  43 ++++++-
>  arch/x86/include/asm/alternative.h            |  65 +++++++----
>  arch/x86/include/asm/apic.h                   |   2 +-
>  arch/x86/include/asm/barrier.h                |   6 +-
>  arch/x86/include/asm/cpufeature.h             |  30 ++---
>  arch/x86/include/asm/processor.h              |  16 ++-
>  arch/x86/include/asm/smap.h                   |  30 ++---
>  arch/x86/kernel/alternative.c                 | 158 ++++++++++++++++++++++----
>  arch/x86/kernel/cpu/amd.c                     |   5 +
>  arch/x86/kernel/entry_32.S                    |  12 +-
>  arch/x86/lib/clear_page_64.S                  |  66 +++++------
>  arch/x86/lib/copy_page_64.S                   |  37 ++----
>  arch/x86/lib/copy_user_64.S                   |  46 ++------
>  arch/x86/lib/memcpy_64.S                      |  68 ++++-------
>  arch/x86/lib/memmove_64.S                     |  19 +---
>  arch/x86/lib/memset_64.S                      |  61 ++++------
>  arch/x86/um/asm/barrier.h                     |   4 +-
>  tools/perf/bench/mem-memcpy-x86-64-asm-def.h  |   6 +-
>  tools/perf/bench/mem-memcpy-x86-64-asm.S      |   2 -
>  tools/perf/bench/mem-memcpy.c                 | 128 +++++++++++----------
>  tools/perf/bench/mem-memset-x86-64-asm-def.h  |   6 +-
>  tools/perf/bench/mem-memset-x86-64-asm.S      |   2 -
>  tools/perf/util/include/asm/alternative-asm.h |   1 +
>  23 files changed, 433 insertions(+), 380 deletions(-)

Pulled into tip:x86/asm, thanks Boris!

(I made a few comments as replies to the patches themselves, none 
affected the quality of this tree so I pulled it.)

Thanks,

	Ingo

  reply	other threads:[~2015-03-04  7:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 17:06 Borislav Petkov
2015-03-04  7:32 ` Ingo Molnar [this message]
2015-03-04 11:22   ` Borislav Petkov
2015-03-04 11:41     ` Borislav Petkov
2015-03-04 20:22       ` Ingo Molnar
2015-03-04 21:02         ` Borislav Petkov

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=20150304073221.GD22014@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@kernel.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    --subject='Re: [GIT PULL] x86/alternatives padding' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).