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

[Marek Vasut]

On 11/10/2018 03:13 PM, Jan Kiszka wrote:
> 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!

Cool :-)

> 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.

Or use mainline :-)

> 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.

2018.11 should be released in a couple of hours, so you might want to do
that instead.

-- 
Best regards,
Marek Vasut