On Tue, 29 Jan 2013, H. Peter Anvin wrote:
On 01/29/2013 02:15 AM, Russell King - ARM Linux wrote:
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:The only concern I have with that is if someone paints themselves into a
What'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
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)
And if we have a replacement one for one of these, then it should do
exactly that: replace it. I realise that various architectures will
behave differently, so we should really be looking at numbers across
Otherwise, where do we stop adding new ones? After we have 6 of these
(which is after this one). After 12? After the 20th?
corner and absolutely wants, say, LZO.
That would be hard to justify given that the kernel provides its own
decompressor code, making the compression format transparent to
bootloaders, etc. And no one should be poking into the compressed
Otherwise, per your list it pretty much sounds like we should have lz4, gzip,
I do agree with that.