[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWLuo3spcZoSm+68XsmP1ojGTq8q01QxHnyis1QCi5ZxA@mail.gmail.com>
Date: Tue, 24 Nov 2015 16:10:48 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Josh Triplett <josh@...htriplett.org>
Cc: Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Herbert Xu <herbert@...dor.apana.org.au>,
Matt Mackall <mpm@...enic.com>, Chris Mason <clm@...com>,
Josef Bacik <jbacik@...com>, David Sterba <dsterba@...e.com>,
kbuild test robot <fengguang.wu@...el.com>
Subject: Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used
cpu_has_xx macros
On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett <josh@...htriplett.org> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists