All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Peter Lieven <pl@kamp.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()
Date: Thu, 21 Jul 2016 09:12:30 -0600	[thread overview]
Message-ID: <5790E65E.6040605@redhat.com> (raw)
In-Reply-To: <0da28a84-5b9a-ac8c-0bd8-e03cfc824bcb@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2016-07-21 15:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04 13:49 [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes() Peter Lieven
2016-07-05  1:53 ` Eric Blake
2016-07-05  7:30   ` Peter Lieven
2016-07-05 13:03     ` Eric Blake
2016-07-05 13:39       ` Paolo Bonzini
2016-07-05 13:37   ` Paolo Bonzini
2016-07-05 13:40     ` Peter Lieven
2016-07-05 14:59     ` Eric Blake
2016-07-05 15:09       ` Paolo Bonzini
2016-07-15 10:09         ` Peter Lieven
2016-07-15 15:40           ` Eric Blake
2016-07-18  7:06             ` Peter Lieven
2016-07-20 23:35 ` Eric Blake
2016-07-21  7:01   ` Peter Lieven
2016-07-21  9:10     ` Paolo Bonzini
2016-07-21  9:08   ` Paolo Bonzini
2016-07-21 15:12     ` Eric Blake [this message]
2016-07-21 13:38   ` wangweiwei
2016-07-21 13:45     ` wangweiwei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5790E65E.6040605@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.