mmc: core: complete/wait_for_completion performance

[joerg.krause@embedded.rocks (Jörg Krause)]

Hi Stefan,

On Wed, 2016-12-07 at 20:23 +0100, Stefan Wahren wrote:
> Hi J?rg,
> 
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 7. Dezember 2016
> > um 08:32
> > geschrieben:
> > 
> > 
> > Hit Stefan,
> > 
> > On Sat, 2016-11-26 at 20:10 +0100, Stefan Wahren wrote:
> > > Hi J?rg,
> > > 
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > 2016
> > > > um 20:10
> > > > geschrieben:
> > > > 
> > > > 
> > > > On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > November
> > > > > > 2016
> > > > > > um 15:42
> > > > > > geschrieben:
> > > > > > 
> > > > > > 
> > > > > > Hi Stefan,
> > > > > > 
> > > > > > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > > > > > Hi J?rg,
> > > > > > > 
> > > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > > > November
> > > > > > > > 2016
> > > > > > > > um 13:27
> > > > > > > > geschrieben:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I started the discussion on this mailing list in
> > > > > > > > another
> > > > > > > > thread
> > > > > > > > [1],
> > > > > > > > but I'd like to move it to a new thread, because it
> > > > > > > > might
> > > > > > > > be
> > > > > > > > mmc
> > > > > > > > specific.
> > > > > > > > 
> > > > > > > > The issue is that I am noticed low wifi network
> > > > > > > > throughput
> > > > > > > > on
> > > > > > > > an
> > > > > > > > i.MX28
> > > > > > > > board with the mainline kernel (v4.7.10, about 6 Mbps)
> > > > > > > > compared
> > > > > > > > to
> > > > > > > > the
> > > > > > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The
> > > > > > > > wifi
> > > > > > > > chip
> > > > > > > > is
> > > > > > > > attached using the SDIO interface.
> > > > > > > > 
> > > > > > > > I started investigation where the bottleneck in the
> > > > > > > > mainline
> > > > > > > > kernel?might come from. Therefore I checked that the
> > > > > > > > configs
> > > > > > > > and
> > > > > > > > settings for the interfaces and drivers are the same.
> > > > > > > > They
> > > > > > > > are.
> > > > > > > 
> > > > > > > so you're not using the mxs_defconfig settings anymore?
> > > > > > 
> > > > > > No, I changed the settings.
> > > > > > 
> > > > > 
> > > > > What happens to performance to if you change the following
> > > > > settings
> > > > > to the same
> > > > > like in mxs_defconfig?
> > > > > 
> > > > > CONFIG_PREEMPT_VOLUNTARY=y
> > > > > CONFIG_DEFAULT_IOSCHED="noop"
> > > > 
> > > > No much change at all. The time difference between complete()
> > > > and
> > > > wait_for_complete() decreases in best case to 110 us, but also
> > > > varies
> > > > to above 130 us.
> > > 
> > > just a weird idea. Did you tried to add MMC_CAP_CMD23 into the
> > > caps
> > > [1]?
> > > 
> > > [1] - http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-m
> > > mc.c
> > > ?v=4.8#L642
> > 
> > I tried, but it did not improved the timing or throughput. However,
> > many thanks for the input.
> > 
> > J?rg
> 
> did you try cyclictest [1]?

Not yet. Not sure what to measure and which values to compare here.

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

> [1] - https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/

Best regards
J?rg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mmc-mxs-mmc-drop-DMA-and-use-polling-mode.patch
Type: text/x-patch
Size: 7570 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/c2c74830/attachment-0001.bin>