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