Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux:Yes, the larger image could matter. Definitely it takes longer.On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:the problem gets more complicated as the "fastest" decompressor usuallyWhat's this "with enabled unaligned memory access" thing? You mean "ifWell... when I saw this my immediate reaction was "oh no, yet another
the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
that's only x86, which isn't really in the target market for this
patch, yes?
It's a lot of code for a 50ms boot-time improvement. Does anyone have
any opinions on whether or not the benefits are worth the cost?
decompressor for the kernel". We have five of these things already.
Do we really need a sixth?
My feeling is that we should have:
- one decompressor which is the fastest
- one decompressor for the highest compression ratio
- one popular decompressor (eg conventional gzip)
creates larger images which need more time to load from the storage, e.g. a
one MB larger image on a 10 MB/s storage (note: bootloaders often configure
the storage controllers in slow modes) gives 100 ms more boot time, thus
eating the gain of a "fast decompressor".