From: Konstantin Dorfman <kdorfman@codeaurora.org>
To: linux-mmc@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org,
Konstantin Dorfman <kdorfman@codeaurora.org>
Subject: [PATCH] mmc: fix async request mechanism for sequential read scenarios
Date: Tue, 2 Oct 2012 17:39:37 +0200 [thread overview]
Message-ID: <1349192378-1676-1-git-send-email-kdorfman@codeaurora.org> (raw)
In-Reply-To: <n>
The main assumption of the async request design is that the file
system adds block requests to the block device queue asynchronously
without waiting for completion (see the Rationale section of
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req).
We found out that in case of sequential read operations this is not
the case, due to the read ahead mechanism.
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.
This patch fixes the above behavior and allows the async request mechanism
to work in case of sequential read scenarios.
The main idea is to replace the blocking wait for a completion with an
event driven mechanism and add a new event of new_request.
When the block layer notifies the MMC layer on a new request, we check
for the above case where MMC layer is waiting on a previous request
completion and the current request is NULL.
In such a case the new_request event will be triggered to wakeup
the waiting thread. MMC layer will then fetch the new request
and after its preparation will go back to waiting on the completion.
Our tests showed that this fix improves the read sequential throughput
by 16%.
Konstantin Dorfman (1):
mmc: fix async request mechanism for sequential read scenarios
drivers/mmc/card/block.c | 30 ++++-----
drivers/mmc/card/queue.c | 34 ++++++++-
drivers/mmc/card/queue.h | 1 +
drivers/mmc/core/core.c | 165 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mmc/card.h | 12 ++++
include/linux/mmc/core.h | 21 ++++++
6 files changed, 243 insertions(+), 20 deletions(-)
--
1.7.6
--
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-02 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 15:39 Konstantin Dorfman [this message]
2012-10-02 15:39 ` [PATCH] mmc: fix async request mechanism for sequential read scenarios Konstantin Dorfman
2012-10-11 15:19 ` Per Forlin
2012-10-14 16:17 ` Konstantin Dorfman
2012-10-21 22:22 ` Per Forlin
-- strict thread matches above, loose matches on Subject: below --
2012-10-02 15:36 Konstantin Dorfman
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=1349192378-1676-1-git-send-email-kdorfman@codeaurora.org \
--to=kdorfman@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-mmc@vger.kernel.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).