From: merez@codeaurora.org
To: "S, Venkatraman" <svenkatr@ti.com>
Cc: merez@codeaurora.org, Seungwon Jeon <tgih.jun@samsung.com>,
linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
DOCUMENTATION' <linux-doc@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control
Date: Mon, 11 Jun 2012 13:19:48 -0700 (PDT) [thread overview]
Message-ID: <4c35449ed272eb5831cf2f8765eeeb48.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <CANfBPZ-HukGqES4eUhxfDhLy+Sj6XJEyPu9kgKCAddPnVyoqKA@mail.gmail.com>
> On Sat, Jun 9, 2012 at 8:16 PM, <merez@codeaurora.org> wrote:
>>
>>> Hi,
>>>
>>> How can we check the effect?
>>> Do you have any result?
>> We ran parallel lmdd read and write operations and found out that the
>> write packing causes the read throughput to drop from 24MB/s to 12MB/s.
>
> Whoa! That's a big drop.
> BTW, is there a problem with throughput or latency, or both ?
> If these numbers are over long duration (>5 seconds), then where are
> the cycles going?
> It would be nice to see some blktrace figures for the issue, and then fix
> it,
> rather than apply a band aid like the write-packing-control on top..
I believe this is because the write packing changes the dispatching policy
of the scheduler. Without write packing only 2 write requests were
fetched, giving the read requests a chance to be inserted into the
scheduler while we wait for the completion of the first write request.
Then when the next fetch was performed the read request would be the
chosen one. When write packing is enabled we keep fetching all the write
requests that are queued (assuming there are no read requests inserted
yet) and when the read is inserted and fetched is has to wait for the
completion of a bigger amount of write requests.
>
>
>> The write packing control managed to increase the read throughput back
>> to
>> the original value.
>> We also examined "real life" scenarios, such as performing a big push
>> operation in parallel to launching several applications. We measured the
>> read latency and found out that with the write packing control the worst
>> case of the read latency was smaller.
>>
>>> Please check the several comment below.
>>>
>>> Maya Erez <merez@codeaurora.org> wrote:
>>>> The write packing control will ensure that read requests latency is
>>>> not increased due to long write packed commands.
>>>>
>>>> The trigger for enabling the write packing is managing to pack several
>>>> write requests. The number of potential packed requests that will
>>>> trigger
>>>> the packing can be configured via sysfs by writing the required value
>>>> to:
>>>> /sys/block/<block_dev_name>/num_wr_reqs_to_start_packing.
>>>> The trigger for disabling the write packing is fetching a read
>>>> request.
>>>>
>
Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
next prev parent reply other threads:[~2012-06-11 20:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 18:55 [PATCH v2 0/1] mmc: block: Add write packing control Maya Erez
2012-06-01 18:55 ` [PATCH v2 1/1] " Maya Erez
2012-06-08 9:37 ` Seungwon Jeon
2012-06-09 14:46 ` merez
2012-06-11 9:10 ` Seungwon Jeon
2012-06-11 13:55 ` merez
2012-06-11 14:39 ` S, Venkatraman
2012-06-11 20:10 ` merez
2012-06-12 4:16 ` S, Venkatraman
2012-06-11 17:19 ` S, Venkatraman
2012-06-11 20:19 ` merez [this message]
2012-06-12 4:07 ` S, Venkatraman
2012-06-11 21:19 ` Muthu Kumar
2012-06-12 0:28 ` Muthu Kumar
2012-06-12 20:08 ` merez
2012-06-13 19:52 ` merez
2012-06-13 22:21 ` Muthu Kumar
2012-06-14 7:46 ` merez
2012-07-14 19:12 ` Chris Ball
2012-07-16 1:49 ` Muthu Kumar
2012-07-16 2:46 ` Chris Ball
2012-07-16 16:44 ` Muthu Kumar
2012-07-17 22:50 ` Chris Ball
2012-07-18 6:34 ` merez
2012-07-18 7:26 ` Chris Ball
2012-07-19 0:33 ` Muthu Kumar
2012-07-17 4:15 ` S, Venkatraman
-- strict thread matches above, loose matches on Subject: below --
2012-06-12 19:05 merez
2012-07-23 11:43 merez
2012-07-23 12:22 ` S, Venkatraman
2012-07-24 8:44 merez
2012-07-24 20:23 ` merez
2012-07-24 20:52 ` merez
2012-07-26 15:28 ` S, Venkatraman
2012-07-26 18:54 ` merez
2012-07-27 9:07 ` S, Venkatraman
2012-08-27 18:28 ` merez
2012-08-28 17:40 ` S, Venkatraman
2012-09-06 5:17 ` merez
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=4c35449ed272eb5831cf2f8765eeeb48.squirrel@www.codeaurora.org \
--to=merez@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=svenkatr@ti.com \
--cc=tgih.jun@samsung.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 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).