Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

[Andy Lutomirski]

On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/