initramfs - compressed vs. uncompressed

zacariaz · 2012-09-02 00:01:00

I just recently came to think about this. It's common practice to compress iniramfs, but an uncompressed initramfs is also an option.

But what about the pros and cons? How time consuming is the decompression actually and what will the extra size of an uncompressed image mean?

Personally I've got an SSD, so that helps with the extra size and as for the decompression, I am using as rather limited atom CPU, so in theory it seems to work out for me at least.

So, what do you think, that is theoretically, what is the best way to go? In reality of course, the difference is negligible, maybe not even measurable, but that's not really the point.

I'll look forward to your answers.

Best regards.

falconindy · 2012-09-02 00:03:44

The difference in decompression speed is not negligible. If you're going to use compression, I suggest using gzip. lsinitcpio attempts to estimate how long decompression will take, if you're interested in seeing the difference.

WonderWoofy · 2012-09-02 00:05:19

I think that you should just try it and see what happens. From what I have read, some SSD controllers utilize compression anyway. So you can actually have performance decreases if you are accessing/writing data that is already compressed or otherwise uncompressable. So I guess it would just depend greatly on your hardware.

I would be very interested to hear how big an uncompressed initramfs is... so try it!

zacariaz · 2012-09-02 00:25:55

uncompressed image: 6377472
gzip compressed image: 2484699

That's an additional ~150%, which I think is significant, but the files are still relatively small.

Estimated extraction time for uncompressed image: 0.012s
Estimated extraction time for gzip compressed image: 0.167s

That's an additional ~1300% for gzip compression.

So far it don't look too bad for the uncompressed image, but there's still the issue of loading the file of the disk. If it take longer than ~0.150s (in my case), then it's pointless, which of course it is anyway.

Anyway, any ideas as to how I can test the read speed of my SSD?

WonderWoofy · 2012-09-02 00:29:45

if you are using systemd, you can use systemd-analyze to get the time it takes to load the kernel.

zacariaz · 2012-09-02 00:31:20

really? I'll have to investigate that.

thanks.

zacariaz · 2012-09-02 00:38:49

uncompressed: 1163ms (kernel) + 1486ms (userspace) = 2650ms
gzip compressed: 1301ms (kernel) + 1495ms (userspace) = 2797ms

So apparently it is better, in my case that is, to go with an uncompreseed initramfs image.

WonderWoofy · 2012-09-02 00:41:09

Wow, very interesting indeed. I have to say that the difference is negligeable though. In fact I would have to imagine that it is not statistically significant. Were those averages of a few runs or one run per initramfs?

zacariaz · 2012-09-02 00:47:36

WonderWoofy wrote:

Wow, very interesting indeed. I have to say that the difference is negligeable though. In fact I would have to imagine that it is not statistically significant. Were those averages of a few runs or one run per initramfs?

Just one run, but I'm quite sure there is very little variation, though I can try an investigate further.

As for the time savings being negligible, I said exactly that in my initial post, however, 150ms is still 150 ms. and on some systems, the difference may be significantly higher.

What interests me most is how is would look like if I didn't have an SSD, but that's an experiment for another day as I would have to update my other computer, which I really am not looking forward too.

WonderWoofy · 2012-09-02 00:54:39

If you ever took statistics, what I mean is that I would have to imagine that the standard deviation (average of the average deviation) would probably be somewhere near that difference. So the overall Z score would probably render it insignificant in terms of labeling the two correlated. Though this is pure speculation without a data set.

zacariaz · 2012-09-02 01:01:48

WonderWoofy wrote:

If you ever took statistics, what I mean is that I would have to imagine that the standard deviation (average of the average deviation) would probably be somewhere near that difference. So the overall Z score would probably render it insignificant in terms of labeling the two correlated. Though this is pure speculation without a data set.

just for the sake of argument, I'm done some last minute testing (I really need to get to bed) and kernel load time is very stable in general, something like and divination of 10ms, though there is the occasional fluke where it's extra fast, about 30-40ms. I'm not actually sure what courses it though.

as for the userspace time, that fluctuates, but that is to be expected.

edit:
just wanted to make clear that testing this properly will involve a lot of rebooting.

Last edited by zacariaz (2012-09-02 01:04:12)

WonderWoofy · 2012-09-02 01:08:17

zacariaz wrote:

just wanted to make clear that testing this properly will involve a lot of rebooting.

Yes it will Which is why I dind't want to try it myself.

In my mind, it would make sense to me that the uncompressed kernel would be pretty consistent. but I would also think that you might get a bit more variation with a compressed kernel since you are dealing with more variables. BTW, from my experiences, lzop is a tad faster, though not much at all.

zacariaz · 2012-09-02 01:12:10

I would bet that loading of the kernel in to RAM is actually very consistent, but what else is happening in what systemd-analyze calls "kernel space" I can not say. In the end though, I should just keep my mouth shut as I really don't know what I'm talking about

WonderWoofy · 2012-09-02 02:04:06

Well, that is what I was trying to say, the loading of an uncompressed kernel into ram should be more consistent than having to decompress it because the decompression would just add another variable to the process of loading the kernel. Hence, it might not be quite as consistent.

blackout23 · 2012-09-03 18:46:22

I have done 5 runs of uncompressed and gzip initramfs.
CPU is Core i7 2600K 4,5 Ghz

archbox% sudo systemd-analyze 
Startup finished in 1328ms (kernel) + 311ms (userspace) = 1640ms
archbox% sudo systemd-analyze
Startup finished in 1338ms (kernel) + 277ms (userspace) = 1616ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 274ms (userspace) = 1580ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 304ms (userspace) = 1610ms
archbox% sudo systemd-analyze
Startup finished in 1302ms (kernel) + 287ms (userspace) = 1590ms


Gzip:
archbox% sudo systemd-analyze           
Startup finished in 1375ms (kernel) + 347ms (userspace) = 1723ms
archbox% sudo systemd-analyze
Startup finished in 1375ms (kernel) + 331ms (userspace) = 1706ms
archbox% sudo systemd-analyze
Startup finished in 1368ms (kernel) + 351ms (userspace) = 1720ms
archbox% sudo systemd-analyze
Startup finished in 1385ms (kernel) + 340ms (userspace) = 1725ms
archbox% sudo systemd-analyze
Startup finished in 1402ms (kernel) + 351ms (userspace) = 1753ms

Even on a faster CPU you can measure a difference between compressed and uncompressed.
If you add the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and rebuild your initramfs, systemd-analyze will also be able to show you how much time was spent in the initramfs alone. Without it kernel is basically both combined.

Last edited by blackout23 (2012-09-03 18:49:27)

zacariaz · 2012-09-03 19:12:09

blackout23 wrote:

I have done 5 runs of uncompressed and gzip initramfs.
CPU is Core i7 2600K 4,5 Ghz

archbox% sudo systemd-analyze 
Startup finished in 1328ms (kernel) + 311ms (userspace) = 1640ms
archbox% sudo systemd-analyze
Startup finished in 1338ms (kernel) + 277ms (userspace) = 1616ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 274ms (userspace) = 1580ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 304ms (userspace) = 1610ms
archbox% sudo systemd-analyze
Startup finished in 1302ms (kernel) + 287ms (userspace) = 1590ms


Gzip:
archbox% sudo systemd-analyze           
Startup finished in 1375ms (kernel) + 347ms (userspace) = 1723ms
archbox% sudo systemd-analyze
Startup finished in 1375ms (kernel) + 331ms (userspace) = 1706ms
archbox% sudo systemd-analyze
Startup finished in 1368ms (kernel) + 351ms (userspace) = 1720ms
archbox% sudo systemd-analyze
Startup finished in 1385ms (kernel) + 340ms (userspace) = 1725ms
archbox% sudo systemd-analyze
Startup finished in 1402ms (kernel) + 351ms (userspace) = 1753ms

Even on a faster CPU you can measure a difference between compressed and uncompressed.
If you add the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and rebuild your initramfs, systemd-analyze will also be able to show you how much time was spent in the initramfs alone. Without it kernel is basically both combined.

I dare say the difference is less than a pitiful atom CPU, still interesting that the difference is still there though.

I am however done timing the initramfs. I know now which is best for me.

One thing that catches my eyes is the userspace time. the kernel time is not too different between our two setups, but the userspace is apparently very much so. Is that simply because the CPU play a greater role or do you utilize some fancy optimization technique I haven't heard of?

progandy · 2012-09-03 19:15:10

If you want to measure your initramfs, then you should add the "timestamp"-hook as last entry in your config and rebuild the image.
By the way, did you notice that in your case the SSD is so fast that the difference in the boot time is nearly the time saved from decompression.

Last edited by progandy (2012-09-03 19:17:45)

zacariaz · 2012-09-03 19:22:15

progandy wrote:

If you want to measure your initramfs, then you should add the "timestamp"-hook as last entry in your config and rebuild the image.
By the way, did you notice that in your case the SSD is so fast that the difference in the boot time is nearly the time saved from decompression.

As for the timestamp, already mentioned

As for the SSD speed. Yes I did actually

However, those times does fluctuate, so I don't think it should be taken too seriously.

WonderWoofy · 2012-09-03 19:49:30

zacariaz wrote:

However, those times does fluctuate, so I don't think it should be taken too seriously.

I think it is clear if you read the thread that our intentions were not of a serious nature in testing this.

I moved the relevant files (initramfs and kernel) to my ssd efi system partition and briefly tested lzop vs uncompressed. Difference was definitely negligeable, so I think I will stick w/ lzop. My initramfs load time w/ lzop was 2600-2750ms while uncompressed was typically ~2400ms... interesting though.

blackout23 · 2012-09-03 20:04:05

zacariaz wrote:

blackout23 wrote:
I have done 5 runs of uncompressed and gzip initramfs.
CPU is Core i7 2600K 4,5 Ghz
archbox% sudo systemd-analyze 
Startup finished in 1328ms (kernel) + 311ms (userspace) = 1640ms
archbox% sudo systemd-analyze
Startup finished in 1338ms (kernel) + 277ms (userspace) = 1616ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 274ms (userspace) = 1580ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 304ms (userspace) = 1610ms
archbox% sudo systemd-analyze
Startup finished in 1302ms (kernel) + 287ms (userspace) = 1590ms


Gzip:
archbox% sudo systemd-analyze           
Startup finished in 1375ms (kernel) + 347ms (userspace) = 1723ms
archbox% sudo systemd-analyze
Startup finished in 1375ms (kernel) + 331ms (userspace) = 1706ms
archbox% sudo systemd-analyze
Startup finished in 1368ms (kernel) + 351ms (userspace) = 1720ms
archbox% sudo systemd-analyze
Startup finished in 1385ms (kernel) + 340ms (userspace) = 1725ms
archbox% sudo systemd-analyze
Startup finished in 1402ms (kernel) + 351ms (userspace) = 1753ms
Even on a faster CPU you can measure a difference between compressed and uncompressed.
If you add the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and rebuild your initramfs, systemd-analyze will also be able to show you how much time was spent in the initramfs alone. Without it kernel is basically both combined.
I dare say the difference is less than a pitiful atom CPU, still interesting that the difference is still there though.
I am however done timing the initramfs. I know now which is best for me.
One thing that catches my eyes is the userspace time. the kernel time is not too different between our two setups, but the userspace is apparently very much so. Is that simply because the CPU play a greater role or do you utilize some fancy optimization technique I haven't heard of?

Try systemd-analyze blame and see what takes the most time. If it's NetworkManager try setting ipv6 to "Ignore" in your settings and assign a static ip.
Other than that I don't run any extra services and mount only my SSD no external drives. Also added "quiet" to the kernel line which seems to save 100 ms, because
it doesn't have to wait for the console to output all the messages. The longest part of the whole boot is switching from console to the xorg server which take about 2 seconds.
After that my desktop is already fully loaded and ready to use.

Last edited by blackout23 (2012-09-03 20:05:55)

zacariaz · 2012-09-03 20:05:36

blackout23 wrote:

zacariaz wrote:
blackout23 wrote:
I have done 5 runs of uncompressed and gzip initramfs.
CPU is Core i7 2600K 4,5 Ghz
archbox% sudo systemd-analyze 
Startup finished in 1328ms (kernel) + 311ms (userspace) = 1640ms
archbox% sudo systemd-analyze
Startup finished in 1338ms (kernel) + 277ms (userspace) = 1616ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 274ms (userspace) = 1580ms
archbox% sudo systemd-analyze
Startup finished in 1305ms (kernel) + 304ms (userspace) = 1610ms
archbox% sudo systemd-analyze
Startup finished in 1302ms (kernel) + 287ms (userspace) = 1590ms


Gzip:
archbox% sudo systemd-analyze           
Startup finished in 1375ms (kernel) + 347ms (userspace) = 1723ms
archbox% sudo systemd-analyze
Startup finished in 1375ms (kernel) + 331ms (userspace) = 1706ms
archbox% sudo systemd-analyze
Startup finished in 1368ms (kernel) + 351ms (userspace) = 1720ms
archbox% sudo systemd-analyze
Startup finished in 1385ms (kernel) + 340ms (userspace) = 1725ms
archbox% sudo systemd-analyze
Startup finished in 1402ms (kernel) + 351ms (userspace) = 1753ms
Even on a faster CPU you can measure a difference between compressed and uncompressed.
If you add the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and rebuild your initramfs, systemd-analyze will also be able to show you how much time was spent in the initramfs alone. Without it kernel is basically both combined.
I dare say the difference is less than a pitiful atom CPU, still interesting that the difference is still there though.
I am however done timing the initramfs. I know now which is best for me.
One thing that catches my eyes is the userspace time. the kernel time is not too different between our two setups, but the userspace is apparently very much so. Is that simply because the CPU play a greater role or do you utilize some fancy optimization technique I haven't heard of?
Try systemd-analyze blame and see what takes the most time. If it's NetworkManager try setting ipv6 to "Ignore" in your settings and assign a static ip.
Other than that I don't run any extra services and mount only my SSD no external drives.

Good point, always forget about ipv6. Isn't there a kernel param to disable it btw?

Edit:
WICD is responcible for 922ms

Last edited by zacariaz (2012-09-03 20:07:04)

WonderWoofy · 2012-09-03 20:24:09

ipv6.disable=1

zacariaz · 2012-09-03 20:25:27

WonderWoofy wrote:

ipv6.disable=1

Ya sorry, thought I wrote that I figured that out, but it didn't make any difference anyway.

Thanks though.

zacariaz · 2012-09-03 20:34:05

One thing that just popped into my mind.
I use one single ext4 partition, no boot or even a swap partition.

Does this in anyway affect the performance?

WonderWoofy · 2012-09-03 20:38:21

I would think that fsck would take a tad longer... assuming that "pass" in your fstab is 1 for your /, it just means that a larger partition will get priority fsck everytime.

Arch Linux

#1 2012-09-02 00:01:00

initramfs - compressed vs. uncompressed

#2 2012-09-02 00:03:44

Re: initramfs - compressed vs. uncompressed

#3 2012-09-02 00:05:19

Re: initramfs - compressed vs. uncompressed

#4 2012-09-02 00:25:55

Re: initramfs - compressed vs. uncompressed

#5 2012-09-02 00:29:45

Re: initramfs - compressed vs. uncompressed

#6 2012-09-02 00:31:20

Re: initramfs - compressed vs. uncompressed

#7 2012-09-02 00:38:49

Re: initramfs - compressed vs. uncompressed

#8 2012-09-02 00:41:09

Re: initramfs - compressed vs. uncompressed

#9 2012-09-02 00:47:36

Re: initramfs - compressed vs. uncompressed

#10 2012-09-02 00:54:39

Re: initramfs - compressed vs. uncompressed

#11 2012-09-02 01:01:48

Re: initramfs - compressed vs. uncompressed

#12 2012-09-02 01:08:17

Re: initramfs - compressed vs. uncompressed

#13 2012-09-02 01:12:10

Re: initramfs - compressed vs. uncompressed

#14 2012-09-02 02:04:06

Re: initramfs - compressed vs. uncompressed

#15 2012-09-03 18:46:22

Re: initramfs - compressed vs. uncompressed

#16 2012-09-03 19:12:09

Re: initramfs - compressed vs. uncompressed

#17 2012-09-03 19:15:10

Re: initramfs - compressed vs. uncompressed

#18 2012-09-03 19:22:15

Re: initramfs - compressed vs. uncompressed

#19 2012-09-03 19:49:30

Re: initramfs - compressed vs. uncompressed

#20 2012-09-03 20:04:05

Re: initramfs - compressed vs. uncompressed

#21 2012-09-03 20:05:36

Re: initramfs - compressed vs. uncompressed

#22 2012-09-03 20:24:09

Re: initramfs - compressed vs. uncompressed

#23 2012-09-03 20:25:27

Re: initramfs - compressed vs. uncompressed

#24 2012-09-03 20:34:05

Re: initramfs - compressed vs. uncompressed

#25 2012-09-03 20:38:21

Re: initramfs - compressed vs. uncompressed

Board footer