mmc: core: complete/wait_for_completion performance

[Jörg Krause]

Hi Stefan,

On Thu, 2016-12-15 at 19:51 +0100, Stefan Wahren wrote:
> Hi Jörg,
> 
> > Jörg Krause <joerg.krause at embedded.rocks> hat am 15. Dezember 2016
> > um 14:50 geschrieben:
> > 
> > 
> > Hi Stefan,
> > 
> > On Wed, 2016-12-14 at 19:57 +0100, Stefan Wahren wrote:
> > > Hi Jörg,
> > > 
> > 
> > [snip]
> > 
> > > > > 
> > > > > did you try cyclictest [1]?
> > > > 
> > > > Not yet. Not sure what to measure and which values to compare
> > > > here.
> > > 
> > > i tought you have the vendor kernel and the mainline kernel
> > > available
> > > for your platform.
> > > 
> > > So you could compare the both kernels.
> > 
> > Yes, that's right. I will have a look at this tool.
> > 
> > > > 
> > > > > 
> > > > > Beside the time for a request the amount of requests for the
> > > > > complete
> > > > > iperf test
> > > > > would we interesting. Maybe there are retries.
> > > > > 
> > > > > I'm still interested in your PIO mode patches for mxs-mmc
> > > > > even
> > > > > without clean up.
> > > > 
> > > > Actually, the patch does not implement a PIO mode, but drops
> > > > DMA
> > > > and
> > > > uses polling instead. I've attached the patch.
> > > 
> > > Thanks. I applied it, but unfortunately this breaks SD card
> > > support
> > > for my Duckbill and the kernel isn't able to mount the rootfs:
> > > 
> > > [    2.267073] mxs-mmc 80010000.ssp: initialized
> > > [    2.272624] mxs-mmc 80010000.ssp: AC command error 0xffffff92
> > 
> > Sorry, I messed up the branches. I attached the correct patch which
> > is
> > working for me on Linux v4.9.
> 
> i tested the second version but there isn't any performance gain with
> the patch.

In the vendor kernel the polling is used only for small chunks of <=
1024 bytes to save the context switches when using DMA. This patch does
not use DMA at all, but only polling.

As I said before, I guess the limitation in the mxs-mmc driver is the
time needed to return the mmc request to the mmc core driver.

I have a Cubietruck with the same wifi chipset as on my i.MX28 target
where I get ~20Mbps throughput. Furthermore, I've found a benchmark on
a NXP thread [1] measuring about 30Mbps for an i.MX6 target and a
similiar wifi chip.

Looking at the sunxi-mmc driver shows that it calls mmc_request_done()
in an interrupt context and does not use the dmaengine driver at all.

For now, I would drop the polling mode and look how to optimize the
control flow between the DMA controller and the MMC host.
Unfortunately, this will need some time...

> Duckbill with class 10 SD card
> Linux 4.8 without patch
> 
> dd if=/dev/zero of=test bs=1k count=10000
> 10000+0 records in
> 10000+0 records out
> 10240000 bytes (10 MB) copied, 2.68934 s, 3.8 MB/s
> 
> dd if=/dev/zero of=test bs=8k count=10000
> 10000+0 records in
> 10000+0 records out
> 81920000 bytes (82 MB) copied, 8.24305 s, 9.9 MB/s
> 
> 
> Duckbill with class 10 SD card
> Linux 4.8 with patch
> 
> dd if=/dev/zero of=test bs=1k count=10000
> 10000+0 records in
> 10000+0 records out
> 10240000 bytes (10 MB) copied, 3.41193 s, 3.0 MB/s
> 
> dd if=/dev/zero of=test bs=8k count=10000
> 10000+0 records in
> 10000+0 records out
> 81920000 bytes (82 MB) copied, 14.4564 s, 5.7 MB/s
> 
> Additionally i get these warning during boot:
> 
> [    2.278445] mxs-mmc 80010000.ssp: initialized
> [    2.283996] mxs-mmc 80010000.ssp: AC command error -110
> [    2.305158] mxs-mmc 80010000.ssp: AC command error -110
> [    2.322975] mxs-mmc 80010000.ssp: AC command error -110
> [    2.338660] mxs-mmc 80010000.ssp: AC command error -110
> [    2.344289] mxs-mmc 80010000.ssp: AC command error -110
> [    2.365653] mxs-mmc 80010000.ssp: AC command error -110

I get this errors, too. The MMC host is sending some commands and the
MMC client is not (yet) responding to those commands. I haven't looked
any closer at this.

[1] https://community.nxp.com/thread/317396