Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755730AbbKYALN (ORCPT ); Tue, 24 Nov 2015 19:11:13 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:35157 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755711AbbKYALJ (ORCPT ); Tue, 24 Nov 2015 19:11:09 -0500 MIME-Version: 1.0 In-Reply-To: <20151124224211.GA23495@x> References: <1447156122-9379-1-git-send-email-bp@alien8.de> <1447156122-9379-4-git-send-email-bp@alien8.de> <20151124130510.GA21613@pd.tnic> <20151124224211.GA23495@x> From: Andy Lutomirski Date: Tue, 24 Nov 2015 16:10:48 -0800 Message-ID: Subject: Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros To: Josh Triplett Cc: Borislav Petkov , X86 ML , LKML , Peter Zijlstra , Herbert Xu , Matt Mackall , Chris Mason , Josef Bacik , David Sterba , kbuild test robot Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2179 Lines: 43 On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett wrote: >> 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? > > Seems like a good idea to me: that would sacrifice a small amount of > runtime performance in favor of code size. (Note that the config option > should use static_cpu_has when =y, and the slower, smaller method when > =n, so that "allnoconfig" can DTRT.) > > Given that many embedded systems will know exactly what CPU they want to > run on, I'd also love to see a way to set the capabilities of the CPU at > compile time, so that all those checks (and the code within them) can > constant-fold away. > As another idea, the alternatives infrastructure could plausibly be rearranged so that it never exists in memory in decompressed form. We could decompress it streamily and process it as we go. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/