lkml.org 
[lkml]   [2015]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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@joshtriplett.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


\
 
 \ /
  Last update: 2015-11-25 01:21    [W:0.064 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site