Jamie Lokier wrote:
Avi Kivity wrote:
At such a tiny difference, I'm wondering why Linux-AIO exists at all,
as it complicates the kernel rather a lot. I can see the theoretical
appeal, but if performance is so marginal, I'm surprised it's in
there.
Linux aio exists, but that's
Jamie Lokier wrote:
Avi Kivity wrote:
And video streaming on some embedded devices with no MMU! (Due to the
page cache heuristics working poorly with no MMU, sustained reliable
streaming is managed with O_DIRECT and the app managing cache itself
(like a database), and that needs AIO to
Jamie Lokier wrote:
Avi Kivity wrote:
And video streaming on some embedded devices with no MMU! (Due to the
page cache heuristics working poorly with no MMU, sustained reliable
streaming is managed with O_DIRECT and the app managing cache itself
(like a database), and that needs AIO to
Anthony Liguori wrote:
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)?
There's no guarantee that any sort of order will be preserved
Anthony Liguori 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)?
Avi Kivity wrote:
Anthony Liguori wrote:
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)?
There's no guarantee that any sort of order
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,
Avi Kivity wrote:
And video streaming on some embedded devices with no MMU! (Due to the
page cache heuristics working poorly with no MMU, sustained reliable
streaming is managed with O_DIRECT and the app managing cache itself
(like a database), and that needs AIO to keep the request queue
On Tue, Apr 22, 2008 at 3:10 AM, Avi Kivity [EMAIL PROTECTED] wrote:
I'm rooting for btrfs myself.
but could btrfs (when stable) work for migration? i'm curious about
OCFS2 performance on this kind of load...
when i manage to sell the idea of a KVM cluster i'd like to know if i
should try
Jamie Lokier wrote:
Avi Kivity wrote:
Does that mean for the majority of deployments, the slow version is
sufficient. The few that care about performance can use Linux AIO?
In essence, yes. s/slow/slower/ and s/performance/ultimate block device
performance/.
Many deployments
Javier Guerra Giraldez wrote:
On Sunday 20 April 2008, Avi Kivity wrote:
Also, I'd presume that those that need 10K IOPS and above will not place
their high throughput images on a filesystem; rather on a separate SAN LUN.
i think that too; but still that LUN would be accessed by the
Avi Kivity wrote:
At such a tiny difference, I'm wondering why Linux-AIO exists at all,
as it complicates the kernel rather a lot. I can see the theoretical
appeal, but if performance is so marginal, I'm surprised it's in
there.
Linux aio exists, but that's all that can be said for it. It
Avi Kivity wrote:
For the majority of deployments posix aio should be sufficient. The few
that need something else can use Linux aio.
Does that mean for the majority of deployments, the slow version is
sufficient. The few that care about performance can use Linux AIO?
I'm under the
Jamie Lokier wrote:
Avi Kivity wrote:
For the majority of deployments posix aio should be sufficient. The few
that need something else can use Linux aio.
Does that mean for the majority of deployments, the slow version is
sufficient. The few that care about performance can use
On Sunday 20 April 2008, Avi Kivity wrote:
Also, I'd presume that those that need 10K IOPS and above will not place
their high throughput images on a filesystem; rather on a separate SAN LUN.
i think that too; but still that LUN would be accessed by the VM's via one of
these IO emulation
Daniel P. Berrange wrote:
Those cases aren't always discoverable. Linux-aio just falls back to
using synchronous IO. It's pretty terrible. We need a new AIO
interface for Linux (and yes, we're working on this). Once we have
something better, we'll change that to be the default and
Jamie Lokier wrote:
I've basically got a choice of making libvirt always ad '-aio linux'
or never add it at all. My inclination is to the latter since it is
compatible with existing QEMU which has no -aio option. Presumably
'-aio linux' is intended to provide some performance benefit so it'd
Anthony Liguori wrote:
I'm of the view that '-aio auto' would be a really good option - and
when it's proven itself, it should be the default. It could work on
all QEMU hosts: it would pick synchronous IO when there is nothing else.
Right now, not specifying the -aio option is equivalent to
Anthony Liguori wrote:
Right now, not specifying the -aio option is equivalent to your proposed
-aio auto.
I guess I should include an info aio to let the user know what type of
aio they are using. We can add selection criteria later but
semantically, not specifying an explicit -aio
19 matches
Mail list logo
