On Tue, Mar 28, 2017 at 3:38 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 03/28/17 05:01, Chao Peng wrote: >>> >>> I guess the next step would be to use CONFIG_XIP_KERNEL on x86, >>> which requires an uncompressed kernel but has the additional advantage >>> of sharing the read-only sections of the kernel image across virtual >>> machines, resulting in better RAM and cache usage. >> >> That is something we wanna look into :) >> > > It is, but that is a second order thing... especially since the x86 > kernel makes heavy use of self-patching at the moment. What would be > more significant, though, would be to avoid the memcpy() and instead > decode the uncompressed kernel in-place. > Having looked at this code recently, I'd rather fix it differently: use the streaming decompression API and integrate it with the ELF parsing code so we can decompress directly into the actual load location. Also, the parse_elf() code needs some serious improved documentation and robustification. It's absurdly fragile right now. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
