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:	Tue, 12 Jun 2012 09:37:12 +0530
From:	"S, Venkatraman" <svenkatr@...com>
To:	merez@...eaurora.org
Cc:	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 Tue, Jun 12, 2012 at 1:49 AM,  <merez@...eaurora.org> wrote:
>
>> 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.

Which I/O scheduler are you using ? Both CFQ and deadline would do the
balancing
act to prevent writes overwhelming reads. Writes are async and reads
are sync (usually),
so this imbalance would have existed otherwise, packed command or not.

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

Yes - but that should introduce latency, not bandwidth drop - unless you are
using the no-op scheduler.

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