On Fri, Jun 1, 2018 at 8:05 PM, Alex Maclean <mon...@monkeh.net> wrote: > On 01/06/18 12:34, Lucian Cristian wrote: > >> On 30.05.2018 20:22, Martin Tippmann wrote: >>> find /usr | >>> xargs md5sum >> >> I made the test on tl-wr841n-v9 with luci selected >> >> these are the changes to squashfs >> >> --- a/config/Config-images.in >> +++ b/config/Config-images.in >> @@ -149,8 +149,15 @@ menu "Target Images" >> int "Block size (in KiB)" >> depends on TARGET_ROOTFS_SQUASHFS >> default 64 if LOW_MEMORY_FOOTPRINT >> + default 1024 if (SMALL_FLASH && >> !LOW_MEMORY_FOOTPRINT) >> default 256 >> >> + config SQUASHFS_FRAGMENT_CACHE_SIZE >> + int "Number of fragments cached" >> + depends on TARGET_ROOTFS_SQUASHFS >> + default 1 if (SMALL_FLASH && >> !LOW_MEMORY_FOOTPRINT) >> + default 3 >> + >> menuconfig TARGET_ROOTFS_UBIFS >> bool "ubifs" >> default y if USES_UBIFS > > This won't have actually changed the option - you should use > KERNEL_SQUASHFS_FRAGMENT_CACHE_SIZE, > and CONFIG_SQUASHFS_EMBEDDED=y is also needed in the kernel config. > I think this also therefore belongs either in Config-kernel.in or simply > in the subtarget kernel config. > > I did a few tests myself: > > 256K and 3 fragments: > 10608K used after boot, 11408K free after reading /usr > 24.5 seconds from kernel start to wifi link up > > 1024K and 3 fragments: > 14520K after boot, 15204K after reading > 30 seconds to link up > > 1024K and 2 fragments: > 13460K after boot, 14128K after reading > 34.7 seconds to link up > > 1024K and 1 fragment: > 11620K after boot, 12364K after reading > 46.8 seconds to link up > > Certainly quite a lot of memory impact with the larger block size, but > also a quite significant performance impact with the larger reads. > > I'm leaning towards compromising on 2 fragments but I'd like input on that.
Thanks for testing! Did not expect the impact on boot-time. I'm not a dev, 2 looks reasonable for me - maybe add the flag to make menuconfig / .config so that downstream can set it up - for some applications (i.e. freifunk) boot-time does not matter but memory is always scarse. regards Martin _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
