All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alberto Garcia <berto@igalia.com>
To: Peter Lieven <pl@kamp.de>, Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Bug 1483070 <1483070@bugs.launchpad.net>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1483070] [NEW] VIRTIO Sequential Write IOPS limits not working
Date: Fri, 14 Aug 2015 08:26:27 +0200	[thread overview]
Message-ID: <w51fv3mxu5o.fsf@maestria.local.igalia.com> (raw)
In-Reply-To: <9E0FAA0A-D30A-4AA9-8EB6-EAD3FF3954FC@kamp.de>

On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven <pl@kamp.de> wrote:

>>> IOPS limit does not work for VIRTIO devices if the disk workload is
>>> a sequential write.

>> This is probably due to I/O request merging:
>> 
>> Your benchmark application may generate 32 x 4KB write requests, but
>> they are merged by the virtio-blk device into just 1 x 128KB write
>> request.
>> 
>> The merging can happen inside the guest, depending on your benchmark
>> application and the guest kernel's I/O stack.  It also happens in
>> QEMU's virtio-blk emulation.
>> 
>> The most recent versions of QEMU merge both read and write requests.
>> Older versions only merged write requests.
>> 
>> It would be more intuitive for request merging to happen after QEMU
>> I/O throttling checks.  Currently QEMU's I/O queue plug/unplug isn't
>> advanced enough to do the request merging, so it's done earlier in
>> the virtio-blk emulation code.

Alternatively we could keep the original number of requests and pass it
to throttle_account(), but I'm not sure if it's a good idea.

> I wouldn't consider this behavior bad. Instead of virtio-blk merging
> the request the guest could have issued big IOPS right from the
> beginning. If you are concerned that big I/O is harming your storage,
> you can define a maximum iops_size for throttling or limit the maximum
> bandwidth.

That's right. The way throttling.iops-size works is that I/O requests
larger than this are accounted as if they were split into smaller
operations. So, if iops-size is 32KB, a 128KB request will be counted as
4 for the purpose of limiting the number of IOPS.

Berto

  reply	other threads:[~2015-08-14  6:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-10  0:15 [Qemu-devel] [Bug 1483070] [NEW] VIRTIO Sequential Write IOPS limits not working James Watson
2015-08-10  9:59 ` Stefan Hajnoczi
2015-08-13 23:34   ` Peter Lieven
2015-08-14  6:26     ` Alberto Garcia [this message]
2018-08-07 17:43 ` [Qemu-devel] [Bug 1483070] " Thomas Huth
2018-10-07  4:17 ` Launchpad Bug Tracker

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=w51fv3mxu5o.fsf@maestria.local.igalia.com \
    --to=berto@igalia.com \
    --cc=1483070@bugs.launchpad.net \
    --cc=kwolf@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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.