[U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

Jagan Teki jagannadh.teki at gmail.com
Fri Apr 6 06:06:59 UTC 2018


On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
<maxime.ripard at bootlin.com> wrote:
> On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
>> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
>> <maxime.ripard at bootlin.com> wrote:
>> > From: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>> >
>> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> > read 10MB from a fast eMMC device due to excessive delays in polling
>> > loops.
>> >
>> > This commit restructures the main polling loops to use get_timer(...)
>> > to determine whether a (millisecond) timeout has expired.  We choose
>> > not to use the wait_bit function, as we don't need interruptability
>> > with ctrl-c and have at least one case where two bits (one for an
>> > error condition and another one for completion) need to be read and
>> > using wait_bit would have not added to the clarity.
>> >
>> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
>> > 10MB write decreases from 9.302s to 0.884s).
>>
>> Fyi: I've seen significant improvement, but not 10x on A64
>> (bananpi-m64) with read
>>
>> Before this change:
>>
>> => mmc dev 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> => fatload mmc 0:1 $kernel_addr_r Image
>> reading Image
>> 16310784 bytes read in 821 ms (18.9 MiB/s)
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> => ext4load mmc 1:1 $kernel_addr_r Image
>> 16310784 bytes read in 1109 ms (14 MiB/s)
>>
>>
>> After this change:
>>
>> => mmc dev 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> => fatload mmc 0:1 $kernel_addr_r Image
>> 16310784 bytes read in 784 ms (19.8 MiB/s)
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> => ext4load mmc 1:1 $kernel_addr_r Image
>> 16310784 bytes read in 793 ms (19.6 MiB/s)
>
> Yeah, the smaller the file is, the bigger the gain is. Since you have
> an almost twice bigger file, the gains are probably just noise at that
> point and the bottleneck starts to be your MMC.

Acked-by: Jagan Teki <jagan at openedev.com>


More information about the U-Boot mailing list