From: Chris Ball <cjb@laptop.org>
To: merez@codeaurora.org
Cc: Muthu Kumar <muthu.lkml@gmail.com>,
linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
"S, Venkatraman" <svenkatr@ti.com>,
Seungwon Jeon <tgih.jun@samsung.com>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control
Date: Wed, 18 Jul 2012 03:26:24 -0400 [thread overview]
Message-ID: <87vchlmswv.fsf@octavius.laptop.org> (raw)
In-Reply-To: <31ba3fefcfc5352a6c41955a4e07ae8f.squirrel@www.codeaurora.org> (merez@codeaurora.org's message of "Tue, 17 Jul 2012 23:34:38 -0700 (PDT)")
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, merez@codeaurora.org wrote:
> Is there anything else that holds this patch from being pushed to mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means
that we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings:
With Seungwon's patchset ("Support packed write command"):
* I still don't have a good set of representative benchmarks showing
what kind of performance changes come with this patchset. It seems
like we've had a small amount of testing on one controller/eMMC part
combo from Seungwon, and an entirely different test from Maya, and the
results aren't documented fully anywhere to the level of describing
what the hardware was, what the test was, and what the results were
before and after the patchset.
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace before
trying to fix it. Maya has a theory about writes overwhelming reads,
but Venkat doesn't understand why this would explain the observed
bandwidth drop.
With Maya's patchset ("write packing control"):
* Venkat thinks that HPI should be used, and the number-of-requests
metric is too coarse, and it doesn't let you disable packing at the
right time, and you're essentially implementing a new I/O scheduler
inside the MMC subsystem without understanding the root cause for
why that's necessary.
My sense is that there's no way we can solve all of these to
satisfaction in the next week (which is when the merge window will
open), but that by waiting a cycle we might come up with some good
answers.
What do other people think? If you're excited about these patchsets,
now would be a fine time to come forward with your benchmarking results
and to help understand the reads-during-writes regression.
Thanks!
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
WARNING: multiple messages have this Message-ID (diff)
From: Chris Ball <cjb@laptop.org>
To: merez@codeaurora.org
Cc: "Muthu Kumar" <muthu.lkml@gmail.com>,
linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
"open list" <linux-kernel@vger.kernel.org>, "S\,
Venkatraman" <svenkatr@ti.com>,
Seungwon Jeon <tgih.jun@samsung.com>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control
Date: Wed, 18 Jul 2012 03:26:24 -0400 [thread overview]
Message-ID: <87vchlmswv.fsf@octavius.laptop.org> (raw)
In-Reply-To: <31ba3fefcfc5352a6c41955a4e07ae8f.squirrel@www.codeaurora.org> (merez@codeaurora.org's message of "Tue, 17 Jul 2012 23:34:38 -0700 (PDT)")
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, merez@codeaurora.org wrote:
> Is there anything else that holds this patch from being pushed to mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means
that we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings:
With Seungwon's patchset ("Support packed write command"):
* I still don't have a good set of representative benchmarks showing
what kind of performance changes come with this patchset. It seems
like we've had a small amount of testing on one controller/eMMC part
combo from Seungwon, and an entirely different test from Maya, and the
results aren't documented fully anywhere to the level of describing
what the hardware was, what the test was, and what the results were
before and after the patchset.
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace before
trying to fix it. Maya has a theory about writes overwhelming reads,
but Venkat doesn't understand why this would explain the observed
bandwidth drop.
With Maya's patchset ("write packing control"):
* Venkat thinks that HPI should be used, and the number-of-requests
metric is too coarse, and it doesn't let you disable packing at the
right time, and you're essentially implementing a new I/O scheduler
inside the MMC subsystem without understanding the root cause for
why that's necessary.
My sense is that there's no way we can solve all of these to
satisfaction in the next week (which is when the merge window will
open), but that by waiting a cycle we might come up with some good
answers.
What do other people think? If you're excited about these patchsets,
now would be a fine time to come forward with your benchmarking results
and to help understand the reads-during-writes regression.
Thanks!
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
next prev parent reply other threads:[~2012-07-18 7:26 UTC|newest]
Thread overview: 44+ 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-01 18:55 ` 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
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 [this message]
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 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:23 ` merez
2012-07-24 20:52 ` 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=87vchlmswv.fsf@octavius.laptop.org \
--to=cjb@laptop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=merez@codeaurora.org \
--cc=muthu.lkml@gmail.com \
--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 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.