[OpenWrt-Devel] [PATCH] config: extend small_flash feature
mt at i3o.de
Sun Jun 3 20:12:06 EDT 2018
On Fri, Jun 1, 2018 at 8:05 PM, Alex Maclean <monkeh at 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 &&
>> default 256
>> + config SQUASHFS_FRAGMENT_CACHE_SIZE
>> + int "Number of fragments cached"
>> + depends on TARGET_ROOTFS_SQUASHFS
>> + default 1 if (SMALL_FLASH &&
>> + default 3
>> menuconfig TARGET_ROOTFS_UBIFS
>> bool "ubifs"
>> default y if USES_UBIFS
> This won't have actually changed the option - you should use
> 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.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel