From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: kvm-devel@lists.sourceforge.net,
Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [kvm-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Date: Tue, 22 Apr 2008 16:36:20 +0100 [thread overview]
Message-ID: <20080422153616.GC10229@shareable.org> (raw)
In-Reply-To: <480DFE43.8060509@qumranet.com>
Avi Kivity wrote:
> >Perhaps. This raises another point about AIO vs. threads:
> >
> >If I submit sequential O_DIRECT reads with aio_read(), will they enter
> >the device read queue in the same order, and reach the disk in that
> >order (allowing for reordering when worthwhile by the elevator)?
>
> Yes, unless the implementation in the kernel (or glibc) is threaded.
>
> >With threads this isn't guaranteed and scheduling makes it quite
> >likely to issue the parallel synchronous reads out of order, and for
> >them to reach the disk out of order because the elevator doesn't see
> >them simultaneously.
>
> If the disk is busy, it doesn't matter. The requests will queue and the
> elevator will sort them out. So it's just the first few requests that
> may get to disk out of order.
There's two cases where it matters to a read-streaming app:
1. Disk isn't busy with anything else, maximum streaming
performance is desired.
2. Disk is busy with unrelated things, but you're using I/O
priorities to give the streaming app near-absolute priority.
Then you need to maintain overlapped streaming requests,
otherwise disk is given to a lower priority I/O. If that
happens often, you lose, priority is ineffective. Because one
of the streaming requests is usually being serviced, elevator
has similar limitations as for a disk which is not busy with
anything else.
> I haven't considered tape, but this is a good point indeed. I expect it
> doesn't make much of a difference for a loaded disk.
Yes, as long as it's loaded with unrelated requests at the same I/O
priority, the elevator has time to sort requests and hide thread
scheduling artifacts.
Btw, regarding QEMU: QEMU gets requests _after_ sorting by the guest's
elevator, then submits them to the host's elevator. If the guest and
host elevators are both configured 'anticipatory', do the anticipatory
delays add up?
-- Jamie
WARNING: multiple messages have this Message-ID (diff)
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: kvm-devel@lists.sourceforge.net,
Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Date: Tue, 22 Apr 2008 16:36:20 +0100 [thread overview]
Message-ID: <20080422153616.GC10229@shareable.org> (raw)
In-Reply-To: <480DFE43.8060509@qumranet.com>
Avi Kivity wrote:
> >Perhaps. This raises another point about AIO vs. threads:
> >
> >If I submit sequential O_DIRECT reads with aio_read(), will they enter
> >the device read queue in the same order, and reach the disk in that
> >order (allowing for reordering when worthwhile by the elevator)?
>
> Yes, unless the implementation in the kernel (or glibc) is threaded.
>
> >With threads this isn't guaranteed and scheduling makes it quite
> >likely to issue the parallel synchronous reads out of order, and for
> >them to reach the disk out of order because the elevator doesn't see
> >them simultaneously.
>
> If the disk is busy, it doesn't matter. The requests will queue and the
> elevator will sort them out. So it's just the first few requests that
> may get to disk out of order.
There's two cases where it matters to a read-streaming app:
1. Disk isn't busy with anything else, maximum streaming
performance is desired.
2. Disk is busy with unrelated things, but you're using I/O
priorities to give the streaming app near-absolute priority.
Then you need to maintain overlapped streaming requests,
otherwise disk is given to a lower priority I/O. If that
happens often, you lose, priority is ineffective. Because one
of the streaming requests is usually being serviced, elevator
has similar limitations as for a disk which is not busy with
anything else.
> I haven't considered tape, but this is a good point indeed. I expect it
> doesn't make much of a difference for a loaded disk.
Yes, as long as it's loaded with unrelated requests at the same I/O
priority, the elevator has time to sort requests and hide thread
scheduling artifacts.
Btw, regarding QEMU: QEMU gets requests _after_ sorting by the guest's
elevator, then submits them to the host's elevator. If the guest and
host elevators are both configured 'anticipatory', do the anticipatory
delays add up?
-- Jamie
next prev parent reply other threads:[~2008-04-22 15:36 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-17 19:26 [PATCH 1/3] Refactor AIO interface to allow other AIO implementations Anthony Liguori
2008-04-17 19:26 ` [Qemu-devel] " Anthony Liguori
2008-04-17 19:26 ` [PATCH 2/3] Split out posix-aio code Anthony Liguori
2008-04-17 19:26 ` [Qemu-devel] " Anthony Liguori
2008-04-17 19:26 ` [PATCH 3/3] Implement linux-aio backend Anthony Liguori
2008-04-17 19:26 ` [Qemu-devel] " Anthony Liguori
2008-04-18 15:09 ` Marcelo Tosatti
2008-04-18 15:09 ` [Qemu-devel] " Marcelo Tosatti
2008-04-18 15:18 ` Anthony Liguori
2008-04-18 15:18 ` [Qemu-devel] " Anthony Liguori
2008-04-18 17:46 ` Marcelo Tosatti
2008-04-18 17:46 ` [Qemu-devel] " Marcelo Tosatti
2008-04-17 19:38 ` [PATCH 1/3] Refactor AIO interface to allow other AIO implementations Daniel P. Berrange
2008-04-17 19:38 ` [Qemu-devel] Re: [kvm-devel] " Daniel P. Berrange
2008-04-17 19:41 ` Anthony Liguori
2008-04-17 19:41 ` [Qemu-devel] " Anthony Liguori
2008-04-17 20:00 ` Daniel P. Berrange
2008-04-17 20:00 ` [Qemu-devel] " Daniel P. Berrange
2008-04-17 20:05 ` Anthony Liguori
2008-04-17 20:05 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-04-18 12:43 ` Jamie Lokier
2008-04-18 12:43 ` [Qemu-devel] " Jamie Lokier
2008-04-18 15:23 ` Anthony Liguori
2008-04-18 15:23 ` [Qemu-devel] " Anthony Liguori
2008-04-18 16:22 ` [Qemu-devel] " Jamie Lokier
2008-04-18 16:22 ` [Qemu-devel] Re: [kvm-devel] " Jamie Lokier
2008-04-18 16:32 ` [Qemu-devel] " Avi Kivity
2008-04-18 16:32 ` [kvm-devel] " Avi Kivity
2008-04-20 15:49 ` Jamie Lokier
2008-04-20 15:49 ` [kvm-devel] " Jamie Lokier
2008-04-20 18:43 ` Avi Kivity
2008-04-20 18:43 ` [kvm-devel] " Avi Kivity
2008-04-20 23:39 ` Jamie Lokier
2008-04-20 23:39 ` [kvm-devel] " Jamie Lokier
2008-04-21 6:39 ` Avi Kivity
2008-04-21 6:39 ` [kvm-devel] " Avi Kivity
2008-04-21 12:10 ` Jamie Lokier
2008-04-21 12:10 ` [kvm-devel] " Jamie Lokier
2008-04-22 8:10 ` Avi Kivity
2008-04-22 8:10 ` [kvm-devel] " Avi Kivity
2008-04-22 14:28 ` [kvm-devel] " Jamie Lokier
2008-04-22 14:28 ` [kvm-devel] [Qemu-devel] " Jamie Lokier
2008-04-22 14:53 ` Anthony Liguori
2008-04-22 14:53 ` [kvm-devel] " Anthony Liguori
2008-04-22 15:05 ` [kvm-devel] " Avi Kivity
2008-04-22 15:05 ` [kvm-devel] [Qemu-devel] " Avi Kivity
2008-04-22 15:23 ` [kvm-devel] " Jamie Lokier
2008-04-22 15:23 ` [kvm-devel] [Qemu-devel] " Jamie Lokier
2008-04-22 15:12 ` [kvm-devel] " Jamie Lokier
2008-04-22 15:12 ` [kvm-devel] [Qemu-devel] " Jamie Lokier
2008-04-22 15:03 ` Avi Kivity
2008-04-22 15:03 ` [kvm-devel] " Avi Kivity
2008-04-22 15:36 ` Jamie Lokier [this message]
2008-04-22 15:36 ` Jamie Lokier
2008-05-02 16:37 ` Antonio Vargas
2008-05-02 17:18 ` Jamie Lokier
2008-05-02 17:52 ` Anthony Liguori
2008-05-02 18:24 ` Jamie Lokier
2008-04-22 15:47 ` Javier Guerra
2008-04-21 0:31 ` Javier Guerra Giraldez
2008-04-21 6:41 ` Avi Kivity
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=20080422153616.GC10229@shareable.org \
--to=jamie@shareable.org \
--cc=aliguori@us.ibm.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=mtosatti@redhat.com \
--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.