From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 24 Apr 2018 16:16:24 -0400 Subject: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver In-Reply-To: <20180424195758.zz2ykjibi5hyvugg@flea> References: <20180321111858.16576-1-maxime.ripard@bootlin.com> <20180404070612.z6t3zew4zfdmc3pz@flea> <20180424195758.zz2ykjibi5hyvugg@flea> Message-ID: <20180424201624.GD31362@bill-the-cat.ec.rr.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Apr 24, 2018 at 09:57:58PM +0200, Maxime Ripard wrote: > Hi Jagan, > > On Fri, Apr 06, 2018 at 11:36:59AM +0530, Jagan Teki wrote: > > On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard > > 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 > > >> wrote: > > >> > From: Philipp Tomsich > > >> > > > >> > 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 > > Jaehoon doesn't seem to reply at all, can we merge this through the > sunxi tree? Yes. Reviewed-by: Tom Rini -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: