On November 24, 2015 4:10:48 PM PST, Andy Lutomirski <l...@amacapital.net> wrote: >On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett <j...@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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
