linux-kernel - Re: [PATCH v7 1/3] mmc: core: Add packed command feature of eMMC4.5

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANfBPZ_+=keFgv-xDbzkZi2uVFvd46_JGoxweMKa1CvfX=X7=g@mail.gmail.com>
Date:	Thu, 14 Jun 2012 01:19:56 +0530
From:	"S, Venkatraman" <svenkatr@...com>
To:	merez@...eaurora.org
Cc:	Seungwon Jeon <tgih.jun@...sung.com>, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Chris Ball <cjb@...top.org>,
	Subhash Jadavani <subhashj@...eaurora.org>
Subject: Re: [PATCH v7 1/3] mmc: core: Add packed command feature of eMMC4.5

On Wed, Jun 13, 2012 at 12:45 AM,  <merez@...eaurora.org> wrote:
>
>> S, Venkatraman <svenkatr@...com> wrote:
>>> On Mon, Jun 11, 2012 at 1:53 PM, Seungwon Jeon <tgih.jun@...sung.com>
>>> wrote:
>>> > This patch adds packed command feature of eMMC4.5.
>>> > The maximum number for packing read(or write) is offered
>>> > and exception event relevant to packed command which is
>>> > used for error handling is enabled. If host wants to use
>>> > this feature, MMC_CAP2_PACKED_CMD should be set.
>>> >
>>> > Signed-off-by: Seungwon Jeon <tgih.jun@...sung.com>
>>>
>>> Can you please post some clear performance benchmarks with your patchset
>>> ?
>>> Given that #merez claims to see a significant performance drop for
>>> reads, it will be
>>> good to compare notes.
>>> If it's not too much trouble, both CFQ and deadline scheduler figures
>>> would be useful, on a
>>> set of read only, write only and parallel read write usecases.
>>>
>>> I can also try to replicate your results if you can publish the exact
>>> configuration you used
>>> for testing (example: iozone parameters)
>> I'm checking the merez's result.
>> Currently packed command is effective on write.
>> When running packed write with iozone, there is 25% performance gains.
>> (ex: iozone -az -i0 -I -s 10m -f /target/test -e)
>>
> Our tests shows performance gain of 50-60% in scenarios of only write lmdd
> operations.
>
> As I mentioned in the write packing control thread the degradation of read
> performance in case of mix read/write operations appears also without
> write packing. Therefore I don't think it should stop us from approving
> the write packing patch, that gives a significant improvement to the write
> performance.
> The read performance degradation should be resolved regardless of the
> write packing patch.
>

One further question - when you say "degradation of read performance
in case of mix
read/write operations appears also without write packing", what
exactly does that mean?
Degradation w.r.to to read-only test ? Or any expected throughput ?

If the scenario you mention is accurate, I was actually thinking that
we should recommend to merge
read packing first, then merge write packing once the read performance
issue is well understood.

I am all for better performance with packing control etc, but the
overall code complexity is really
increasing more than necessary. I want to make sure that it is really
worth the effort.

Thanks,
Venkat.
--
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/