From: Borislav Petkov <bp@alien8.de>
To: X86 ML <x86@kernel.org>, Josh Triplett <josh@joshtriplett.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andy Lutomirski <luto@amacapital.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
Matt Mackall <mpm@selenic.com>, Chris Mason <clm@fb.com>,
Josef Bacik <jbacik@fb.com>, David Sterba <dsterba@suse.com>,
kbuild test robot <fengguang.wu@intel.com>
Subject: Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros
Date: Tue, 24 Nov 2015 14:05:10 +0100 [thread overview]
Message-ID: <20151124130510.GA21613@pd.tnic> (raw)
In-Reply-To: <1447156122-9379-4-git-send-email-bp@alien8.de>
On Tue, Nov 10, 2015 at 12:48:42PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov <bp@suse.de>
>
> Those are stupid and code should use static_cpu_has_safe() anyway. Kill
> the least used and unused ones.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Chris Mason <clm@fb.com>
> Cc: Josef Bacik <jbacik@fb.com>
> Cc: David Sterba <dsterba@suse.com>
> ---
> arch/x86/crypto/chacha20_glue.c | 2 +-
> arch/x86/crypto/crc32c-intel_glue.c | 3 ++-
> arch/x86/include/asm/cmpxchg_32.h | 2 +-
> arch/x86/include/asm/cpufeature.h | 32 +++--------------------------
> arch/x86/include/asm/smp.h | 2 +-
> arch/x86/kernel/cpu/amd.c | 2 +-
> arch/x86/kernel/cpu/intel.c | 3 ++-
> arch/x86/kernel/cpu/mtrr/generic.c | 2 +-
> arch/x86/kernel/cpu/mtrr/main.c | 2 +-
> arch/x86/kernel/cpu/perf_event_amd.c | 4 ++--
> arch/x86/kernel/cpu/perf_event_amd_uncore.c | 8 ++++----
> arch/x86/kernel/fpu/init.c | 4 ++--
> arch/x86/kernel/hw_breakpoint.c | 3 ++-
> arch/x86/kernel/vm86_32.c | 4 +++-
> arch/x86/mm/setup_nx.c | 4 ++--
> drivers/char/hw_random/via-rng.c | 5 +++--
> drivers/crypto/padlock-aes.c | 2 +-
> drivers/crypto/padlock-sha.c | 3 ++-
> fs/btrfs/disk-io.c | 2 +-
> 19 files changed, 35 insertions(+), 54 deletions(-)
Ok, 0day says this patch makes tiny not so tiny:
i386-tinyconfig vmlinux size:
+-------+------+-------+-----+--------------------------------------------------------------------------------------+
| TOTAL | TEXT | DATA | BSS | |
+-------+------+-------+-----+--------------------------------------------------------------------------------------+
| +4646 | +64 | +4096 | 0 | ab9976b5af96 x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros |
| -32 | -32 | 0 | 0 | 13e835020a02 x86/cpufeature: Cleanup get_cpu_cap() |
| +32 | +32 | 0 | 0 | 3615f94f0486 x86/cpufeature: Move some of the scattered feature bits to x86_capabili |
| +136 | +32 | 0 | 0 | 506d983184f4 Merge branch 'tip-fpu-xsave' into rc2+ |
| +4782 | +96 | +4096 | 0 | ALL COMMITS |
+-------+------+-------+-----+--------------------------------------------------------------------------------------+
Btw, thanks 0day!
The problem comes from static_cpu_has_safe() adding the alternatives and
fallback machinery. For example, before the patch, we had this at the
cpu_has_* testing sites:
movl boot_cpu_data+20, %eax # MEM[(const long unsigned int *)&boot_cpu_data + 20B], D.19113
testl $2097152, %eax #, D.19113
je .L166 #,
and now we get this:
#APP
# 449 "arch/x86/kernel/cpu/intel.c" 1
# 0 "" 2
# 511 "./arch/x86/include/asm/cpufeature.h" 1
1: jmp .L166 #
2:
.skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90
3:
.section .altinstructions,"a"
.long 1b - .
.long 4f - .
.word 117 #
.byte 3b - 1b
.byte 5f - 4f
.byte 3b - 2b
.previous
.section .altinstr_replacement,"ax"
4: jmp .L167 #
5:
.previous
.section .altinstructions,"a"
.long 1b - .
.long 0
.word 21 #
.byte 3b - 1b
.byte 0
.byte 0
.previous
# 0 "" 2
#NO_APP
jmp .L168 #
.L166:
movl $21, %eax #,
call __static_cpu_has_safe #
testb %al, %al # D.19126
je .L167 #,
.L168:
#APP
# 453 "arch/x86/kernel/cpu/intel.c" 1
# 0 "" 2
#NO_APP
That gets spread among .altinstructions, .altinstr_replacement, .text
etc sections. .data grows too probably because of the NOP padding :-\
text data bss dec hex filename
before: 644896 127436 1189384 1961716 1deef4 vmlinux
after: 645446 131532 1189384 1966362 1e011a vmlinux
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
before: [12] .altinstructions PROGBITS c10bdf48 0bef48 000680 00 A 0 0 1
after: [12] .altinstructions PROGBITS c10bff48 0c0f48 0007d2 00 A 0 0 1
before: [13] .altinstr_replace PROGBITS c10be5c8 0bf5c8 00016c 00 AX 0 0 1
after: [13] .altinstr_replace PROGBITS c10c071a 0c171a 0001ad 00 AX 0 0 1
before: [ 7] .data PROGBITS c1092000 093000 0132a0 00 WA 0 0 4096
after: [ 7] .data PROGBITS c1093000 094000 0142a0 00 WA 0 0 4096
So I'm wondering if we should make a config option which converts
static_cpu_has* macros to boot_cpu_has()? That should slim down
the kernel even more but it won't benefit from the speedup of the
static_cpu_has* stuff.
Josh, thoughts?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2015-11-24 13:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 11:48 [RFC PATCH 0/3] x86/cpufeature: Cleanup stuff Borislav Petkov
2015-11-10 11:48 ` [RFC PATCH 1/3] x86/cpufeature: Move some of the scattered feature bits to x86_capability Borislav Petkov
2015-11-10 11:48 ` [RFC PATCH 2/3] x86/cpufeature: Cleanup get_cpu_cap() Borislav Petkov
2015-11-10 11:48 ` [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros Borislav Petkov
2015-11-10 11:57 ` David Sterba
2015-11-10 12:30 ` Ingo Molnar
2015-11-10 12:37 ` Borislav Petkov
2015-11-18 18:23 ` Borislav Petkov
2015-11-24 13:05 ` Borislav Petkov [this message]
2015-11-24 22:42 ` Josh Triplett
2015-11-25 0:10 ` Andy Lutomirski
2015-11-25 2:58 ` Josh Triplett
2015-11-27 13:52 ` Borislav Petkov
2015-11-27 18:04 ` Borislav Petkov
2015-11-27 20:13 ` Josh Triplett
2015-11-27 20:23 ` 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=20151124130510.GA21613@pd.tnic \
--to=bp@alien8.de \
--cc=a.p.zijlstra@chello.nl \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=fengguang.wu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=jbacik@fb.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mpm@selenic.com \
--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.