qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()


From: Eric Blake
Subject: Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()
Date: Thu, 21 Jul 2016 09:12:30 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 07/21/2016 03:08 AM, Paolo Bonzini wrote:
> 
> 
> On 21/07/2016 01:35, Eric Blake wrote:
>> Also, while the device is advertising that the optimal discard alignment
>> is 15M, that does not tell me the minimum granularity that it can
>> actually discard.  Can you determine that value?  That is, if I try to
>> discard only 1M, does that actually result in a 1M allocation hole, or
>> is it ignored?  It sounds like qemu should be tracking 2 separate
>> values: the minimum discard granularity (I suspect this number is a
>> power of 2, at least the block size, and perhaps precisely equal to the
>> block size)
> 
> It's very unlikely to be equal to the block size.  The block size is
> probably 512, perhaps 4096, while the optimal discard alignment is
> usually at least 64K.

It would be nice to determine what the true minimum is, whether it is a
block size, or 64k, or some other number.

> 
>> Or put another way, I get that I can't discard more than 15M at a time.
> 
> I don't think so; optimal discard alignment is 15M but maximum discard
> size is most likely _not_ 15M.

Peter proved that the device itself reports that its optimal size and
maximum size are equal, at 15M each.

> 
>> Optimal size not being a power of 2 is not a problem, but I still
>> suspect MINIMUM alignment is a power of 2, and I need to know how much
>> head and tail to discard in the new byte-based discard routines in order
>> to align requests up to the minimal discard alignment boundaries.
> 
> But why does it matter if it is a power of 2?  Can't you just use
> DIV_ROUND_UP?

Oddly enough, ROUND_UP() requires a power of 2, but is otherwise
identical to QEMU_ALIGN_UP() which does not require a power of 2.
DIV_ROUND_UP() scales down, so I'd have to scale back up, basically
open-coding QEMU_ALIGN_UP() which keeps the scale unchanged.

I'm seriously debating about adding comments to osdep.h on which macros
require a power of 2 or not, and/or a cleanup patch that unifies
ROUND_UP() and QEMU_ALIGN_UP() to be the same functionality (since they
are already the same for power of 2).  A decent compiler should be able
to optimize * and / back into bit twiddling if it knows that the
rounding amount is a power of 2.

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