qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 5/9] block: Pass unaligned discard requests t


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 5/9] block: Pass unaligned discard requests to drivers
Date: Tue, 22 Nov 2016 08:56:42 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/22/2016 08:13 AM, Eric Blake wrote:

>> Hm, from the commit message I expected splitting requests in three
>> (head, bulk, tail), but actually we can end up splitting it in five?
> 
> Correct; so maybe I need to improve the commit message.  The goal in
> multiple splits was to make it easier for drivers to not have to worry
> about re-aligning things (a request is either sub-sector, sub-page but
> sector-aligned, or page-aligned).
> 
>>
>> Just to check whether I got this right, let me try an example: Let's
>> assume request alignment 512, pdiscard alignment 64k, and we get a
>> discard request with offset 510, length 130k. This algorithm makes the
>> following calls to the driver:
>>
>> 1. pdiscard offset=510, len=2               | new count = 130k - 2
>> 2. pdiscard offset=512, len=(64k - 512)     | new count = 66k + 510
>> 3. pdiscard offset=64k, len=64k             | new count = 2558
>> 4. pdiscard offset=128k, len=2048           | new count = 510
>> 5. pdiscard offset=130k, len=510            | new count = 0
>>
>> Correct?
>>
> 
> Yes.

To further clarify: for write zeroes, we have been doing 1+2 and 4+5
together, because if the driver returns -ENOTSUP, we then do a normal
write, and normal writes already take care of fragmenting things back
into alignment boundaries (1 and 5 are handled by read-modify-write, 2
and 4 are aligned to write request boundaries), so the writes happen no
matter what even if the write-zero at request boundaries might have been
more efficient.  With discard, there is no fallback to any other
operation, so we HAVE to present as many fragments as possible to the
driver, while still making it easy for the driver to distinguish between
aligned and unaligned requests and not having to do extra rounding.

But you made me realize that if I make write_zeroes do the same 5-piece
fragmentation, then it might be easier to use bdrv_aligned_pwritev
instead of manually reimplementing max_transfer logic in the write fallback.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]