From: joerg.krause@embedded.rocks (Jörg Krause)
To: linux-arm-kernel@lists.infradead.org
Subject: Low network throughput on i.MX28
Date: Sat, 19 Nov 2016 00:49:01 +0100 [thread overview]
Message-ID: <1479512941.5577.1.camel@embedded.rocks> (raw)
In-Reply-To: <1478360733.3405.17.camel@intel.com>
Hi all,
[snip]
I did some time measurements on the wifi, mmc and dma driver to compare
the performance between the vendor and the mainline kernel. For this I
toggled some GPIOs and measured the time difference with an osci. I
started measuring the time before calling sdio_readsb() in the wifi
driver [1] and stopped the time when the call returns. Note that the
time was only measured for a packet length of 1536 bytes.
The vendor kernel took about 250 us to return whereas the mainline
kernel took about 325 us. To investigate where this additional time
comes from I divided the whole procedure into seperate parts and
compared their time consumed.
I noticed that the mainline kernel does took much longer to return
after the DMA request is done, signalled in this case by calling
mxs_mmc_dma_irq_callback() [2] in the mxs-mmc driver. From here it
takes about 150 us to get back to sdio_readsb().
An example for consuming much more time is the mainline mmc driver
where it hangs in?mmc_wait_done() [2] about 50 us just calling
complete(), whereas the vendor mmc driver almost immediately returns
here.
I wonder why this call to complete consumes so much time? Any ideas?
[1] http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/
brcm80211/brcmfmac/bcmsdh.c#L488
[2] http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c#L17
9
[3] http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L386
Best regards,
J?rg Krause
next prev parent reply other threads:[~2016-11-18 23:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 23:09 Low network throughput on i.MX28 Jörg Krause
2016-10-13 6:48 ` Lothar Waßmann
2016-10-13 19:43 ` Jörg Krause
2016-10-13 20:42 ` Uwe Kleine-König
2016-10-14 6:13 ` Lothar Waßmann
2016-10-15 8:46 ` Jörg Krause
2016-10-15 8:59 ` Stefan Wahren
2016-10-15 9:41 ` Jörg Krause
2016-10-15 16:16 ` Stefan Wahren
2016-10-28 23:07 ` Jörg Krause
2016-10-29 9:08 ` Stefan Wahren
2016-10-29 13:08 ` Jörg Krause
2016-11-02 8:14 ` Jörg Krause
2016-11-02 8:24 ` Stefan Wahren
2016-11-02 8:30 ` Jörg Krause
2016-11-04 18:44 ` Jörg Krause
2016-11-04 19:30 ` Stefan Wahren
2016-11-04 20:56 ` Jörg Krause
2016-11-04 22:42 ` Jörg Krause
2016-11-05 11:33 ` Stefan Wahren
2016-11-05 12:06 ` Jörg Krause
2016-11-05 12:39 ` Koul, Vinod
2016-11-05 12:47 ` Jörg Krause
2016-11-05 12:48 ` Fabio Estevam
2016-11-05 13:14 ` Jörg Krause
2016-11-05 15:45 ` Koul, Vinod
2016-11-05 22:37 ` Jörg Krause
2016-11-18 23:49 ` Jörg Krause [this message]
2016-11-19 11:36 ` Stefan Wahren
2016-11-20 9:14 ` Jörg Krause
2016-10-15 11:18 ` Jörg Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1479512941.5577.1.camel@embedded.rocks \
--to=joerg.krause@embedded.rocks \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).