[U-Boot] 'load mmc' speed varies significantly

[Jan Kiszka]

On 10.11.18 13:35, Marek Vasut wrote:
> On 11/10/2018 09:37 AM, Jan Kiszka wrote:
>> Hi all,
>>
>> I'm getting significant speed differences while loading kernel and
>> initrd from an ext4 rootfs on an SD card via the 'load' command:
>>
>> ## Executing script at 80000000
>> 54764 bytes read in 296 ms (180.7 KiB/s)
>> 12359688 bytes read in 42982 ms (280.3 KiB/s)
>> 4333462 bytes read in 441 ms (9.4 MiB/s)
>>
>> The script just does
>>
>> setenv bootargs root=/dev/mmcblk1p2 rw rootwait
>> load ${devtype} ${devnum}:2 ${fdt_addr_r} /usr/lib/linux-image-4.14.67+/${fdtfile}
>> load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/vmlinuz-4.14.67+
>> load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initrd.img-4.14.67+
>> booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
>>
>> So, the kernel takes an eternity while the initrd on the very same
>> filesystem loads at full speed. Moreover, when I rewrite the kernel like
>> this
>>
>> # cat /boot/vmlinuz-4.14.67+ > /boot/vmlinuz-4.14.67+.rewrite
>> # mv /boot/vmlinuz-4.14.67+.rewrite /boot/vmlinuz-4.14.67+
>>
>> the transfer speed is fine for it as well.
>>
>> I'm currently seeing this on an AM65xx (downstream U-boot, 2018.01-
>> based), but I had the very same effect on other boards (e.g. Orange Pi
>> Zero) with upstream U-boot as well in the past. We generate the
>> filesystem and the SD card image via wic - possibly with some
>> unfortunate parameters?
> 
> Do you have CONFIG_BLOCK_CACHE=y ? It allows U-Boot to cache inode
> content, so it won't have to read them over and over from the storage,
> which introduces a lot of overhead.
> 

Indeed, it was off, and enabling it did the trick!

The reason for being off is also clear now: TI downstream is missing 46960ad6 
(block: Have BLOCK_CACHE default to y in some cases). Lokesh, you possibly want 
to add that to your tree - or update its baseline.

And on Orange Pi, I'm using Debian's prebuilt version which is still 2018.05 in 
buster. Vagrant, if you do not plan to update to 2018.09 from experimental 
anymore before the freeze, that commit would still be valuable to have. The 
issue does not show up consistently: just retried, and the speed is fine also 
with 2018.05.

Thanks,
Jan