From: "Konstantin Dorfman" <kdorfman@codeaurora.org>
To: Per Forlin <per.lkml@gmail.com>
Cc: Konstantin Dorfman <kdorfman@codeaurora.org>,
cjb@laptop.org, linux-mmc@vger.kernel.org
Subject: Re: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios
Date: Wed, 24 Oct 2012 11:41:36 +0200 (IST) [thread overview]
Message-ID: <f67543901d54b344c8bb401e363e6b80.squirrel@www.codeaurora.org> (raw)
Hello Per,
On Mon, October 22, 2012 1:02 am, Per Forlin wrote:
>> When mmcqt reports on completion of a request there should be
>> a context switch to allow the insertion of the next read ahead BIOs
>> to the block layer. Since the mmcqd tries to fetch another request
>> immediately after the completion of the previous request it gets NULL
>> and starts waiting for the completion of the previous request.
>> This wait on completion gives the FS the opportunity to insert the next
>> request but the MMC layer is already blocked on the previous request
>> completion and is not aware of the new request waiting to be fetched.
> I thought that I could trigger a context switch in order to give
> execution time for FS to add the new request to the MMC queue.
> I made a simple hack to call yield() in case the request gets NULL. I
> thought it may give the FS layer enough time to add a new request to
> the MMC queue. This would not delay the MMC transfer since the yield()
> is done in parallel with an ongoing transfer. Anyway it was just meant
> to be a simple test.
>
> One yield was not enough. Just for sanity check I added a msleep as
> well and that was enough to let FS add a new request,
> Would it be possible to gain throughput by delaying the fetch of new
> request? Too avoid unnecessary NULL requests
>
> If (ongoing request is read AND size is max read ahead AND new request
> is NULL) yield();
>
> BR
> Per
We did the same experiment and it will not give maximum possible
performance. There is no guarantee that the context switch which was
manually caused by the MMC layer comes just in time: when it was early
then next fetch still results in NULL, when it was later, then we miss
possibility to fetch/prepare new request.
Any delay in fetch of the new request that comes after the new request has
arrived hits throughput and latency.
The solution we are talking about here will fix not only situation with FS
read ahead mechanism, but also it will remove penalty of the MMC context
waiting on completion while any new request arrives.
Thanks,
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
next reply other threads:[~2012-10-24 9:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 9:41 Konstantin Dorfman [this message]
2012-10-24 17:07 ` [PATCH v1] mmc: fix async request mechanism for sequential read scenarios Per Förlin
2012-10-25 13:28 ` Konstantin Dorfman
2012-10-25 15:02 ` Per Förlin
2012-10-26 12:07 ` Venkatraman S
2012-10-28 13:12 ` Konstantin Dorfman
2012-10-29 21:40 ` Per Forlin
2012-10-30 7:45 ` Per Forlin
2012-10-30 12:23 ` Konstantin Dorfman
2012-10-30 12:19 ` Konstantin Dorfman
2012-10-30 19:57 ` Per Forlin
2012-11-13 21:10 ` Per Forlin
2012-11-14 15:15 ` Konstantin Dorfman
2012-11-15 16:38 ` Per Förlin
2012-11-19 9:48 ` Konstantin Dorfman
2012-11-19 14:32 ` Per Förlin
2012-11-19 21:34 ` Per Förlin
2012-11-20 16:26 ` Konstantin Dorfman
2012-11-20 18:57 ` Konstantin Dorfman
2012-11-26 15:28 ` Konstantin Dorfman
2012-10-28 12:43 ` Konstantin Dorfman
2012-10-26 11:55 ` Venkatraman S
2012-10-28 12:52 ` Konstantin Dorfman
-- strict thread matches above, loose matches on Subject: below --
2012-10-15 15:36 Konstantin Dorfman
2012-10-21 23:02 ` Per Forlin
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=f67543901d54b344c8bb401e363e6b80.squirrel@www.codeaurora.org \
--to=kdorfman@codeaurora.org \
--cc=cjb@laptop.org \
--cc=linux-mmc@vger.kernel.org \
--cc=per.lkml@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.