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
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 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).