2.0rc4 Memory Comparison - It's all good news

[bigpcman]

Some 2.0rc4 memory numbers from meminfo post boot on my development system. In all cases it's amazingly small !

1. microcore no boot options
2. tinycore text
3. tinycore exit to prompt
4. tinycore no boot options

	1	2	3	4
Total	1,035,076	1,035,076	1,035,076	1,035,076
-Free	1,013,480	1,005,588	1,005,532	1,000,192
-Buffers	0	0	0	0
-Cache	13,036	20,708	20,720	20,728
core	8,560	8,780	8,824	14,156

[curaga]

In measuring these things, you should only do so after dropping the caches (to get a fair measurement):
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

This cleans all file system, inode, dentry caches. Here's TC 2.0rc4 text boot in Qemu, before and after dropping caches:

Total     125504   125504
Used      26400    25064
Free      99104     100440

These are numbers from free, but similar practise applies to numbers from meminfo

[bigpcman]

Ok, I remeasured the meminfo numbers after using sudo sh -c "echo 3 > /proc/sys/vm/drop_caches". The results are below. The row I call core is calculated by subtracting from used memory, buffers and cache. I'm wondering why "core" memory for microcore with core extensions +jwm is higher than tinycore with no boot options? I am assuming the cache will simply vary with time but the "core" will be the same or do I still not understand memory usage?

1. microcore no boot options
2. tinycore text
3. tinycore exit to prompt
4. microcore with core exts and jwm
4. tinycore no boot options

	1 -mc	2 -tc-txt	3 -tc-etp	4 -mc-exts	5 -tc
MemTotal:	1,035,076	1,035,076	1,035,076	1,035,076	1,035,076
Used:	20,496	28,416	28,416	30,772	33,432
MemFree:	1,014,580	1,006,660	1,006,660	1,004,304	1,001,644
Buffers:	0	0	0	20	0
Cached:	13,024	20,704	20,712	15,944	20,720
Core	7,472	7,712	7,704	14,808	12,712

[curaga]

Used - cached would leave ram used by apps, the root filesystem IIRC is in the cache number. As to why microcore shows more app ram usage than tinycore with similar content, I think that is the kernel processes doing the loop mounting and live unpacking.

[bigpcman]

Used - cached would leave ram used by apps, the root filesystem IIRC is in the cache number. As to why microcore shows more app ram usage than tinycore with similar content, I think that is the kernel processes doing the loop mounting and live unpacking.

Yes indeed, tcz extension processing does use memory. I loaded tc with just one small tcz (cramfs) and that caused "app ram" to increase by 176kB.  So I guess the microcore core elements are adding about 1.5MB of "app ram" over and above what tinycore with no other tcz extensions would consume.

It's also interesting that Xvesa uses a little more ram in microcore than in tc according to "top".

[curaga]

Yet the compression causes the total ram usage of microcore to be ~3mb less than that of tinycore

[jpeters]

It would be helpful to include speed tests.

[bigpcman]

It would be helpful to include speed tests.

Do you have a particular test in mind?

[curaga]

One test I can think of would be the time to read up a bigger file, one that is in ram in tc and in a core extension in microcore. Things like boot time or time to start X could be harder to measure.

time dd if=/usr/lib/libX11.so.6.2.0 of=/dev/null

[jpeters]

I was interested in boot time (although the mentioned test might serve the purpose).   Crude comparisons with a stop watch would be sufficient.  Saving a few megs of ram isn't so interesting.  

[bigpcman]

I was interested in boot time (although the mentioned test might serve the purpose).   Crude comparisons with a stop watch would be sufficient.  Saving a few megs of ram isn't so interesting.  

Since I had some spare time I ran a few boot measurements. I used our sony laptop so I could boot directly from a usb stick. I averaged the results of each case over 5 restarts.

The laptop is a Sony NS140E t58 Core2 2Ghz. The USB stick is a super talent Pico Series USB drive that has a 28MB read transfer rate. I used the unetbootin-windows-344.exe program to create the usb stick boot system. I started the stop watch at the point I clicked on the linux install function in the boot menu. So the total computer boot time is longer since the bios boot time needs to be added.

Microcore - no tce directory present (base, nolocal norestore noswap) ... 14.2 second boot time

Microcore (norestore noswap tce=sdb1) ... 16 second boot time

Tinycore (base norestore noswap) ... 15.8 second boot time

These are not very interesting numbers since for most of us there will be more delays as a result of backup restore, establishing a swap file and loading extensions.

In the system I used there is of course a hard drive (sda1) present loaded with vista. So the boot up process will try and fail to access it first before going on to the sdb1 usb stick looking for the restore file, swap file and tce folder. So it's important to specify where all these files are in the boot options otherwise there will be significant delays. I avoided these delays by using options like base, norestore, nolocal and noswap.

[jpeters]

Thanks for running that.  If I have it right, there's a savings of a few megs in ram due to the 4 extensions clinging to the HD, the tradeoff being a slight increase in boot time for the additional loops.  

edit: There's something I don't understand about the numbers. If I add back in free mem, cache, and buffers (- core), it looks like tc uses 4192kB less then mc/with core ext.