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
next prev parent 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 [GIT PULL] x86/alternatives padding 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 \
/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.