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

[Josh Triplett]

On November 24, 2015 4:10:48 PM PST, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>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.

That doesn't help when running the uncompressed kernel in place, though. It'd be nice if every use of alternatives and similar mechanisms supported build-time resolution.


--
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/