lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87vchlmswv.fsf@octavius.laptop.org>
Date:	Wed, 18 Jul 2012 03:26:24 -0400
From:	Chris Ball <cjb@...top.org>
To:	merez@...eaurora.org
Cc:	"Muthu Kumar" <muthu.lkml@...il.com>, linux-mmc@...r.kernel.org,
	linux-arm-msm@...r.kernel.org,
	"open list" <linux-kernel@...r.kernel.org>,
	"S\, Venkatraman" <svenkatr@...com>,
	Seungwon Jeon <tgih.jun@...sung.com>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control

Hi,  [removing Jens and the documentation list, since now we're
talking about the MMC side only]

On Wed, Jul 18 2012, merez@...eaurora.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@...top.org>   <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ