linux-kernel - Re: [PATCH v2 1/1] mmc: block: Add write packing control

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]

Date:	Mon, 11 Jun 2012 13:19:48 -0700 (PDT)
From:	merez@...eaurora.org
To:	"S, Venkatraman" <svenkatr@...com>
Cc:	merez@...eaurora.org, "Seungwon Jeon" <tgih.jun@...sung.com>,
	linux-mmc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	"DOCUMENTATION'" <linux-doc@...r.kernel.org>,
	"open list" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] mmc: block: Add write packing control


> On Sat, Jun 9, 2012 at 8:16 PM,  <merez@...eaurora.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@...eaurora.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

--
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/