Andrew Theurer wrote:
disk: read: 17 MB/sec write: 40 MB/sec
This could definitely cause the extra load, especially if it's many
small requests (compared to a few large ones).
I don't have the request sizes at my fingertips, but we have to use a
lot of disks to support this I/O, so I think it's safe to assume there
are a lot more requests than a simple large sequential read/write.
Yes. Well the high context switch rate is the scheduler's way of
telling us to use linux-aio. If "lot's of disks" == 100, with a 3ms
seek time, that's already 60,000 cs/sec.
Really, I think linux-aio support can help here.
Yes, I think that would work for real block devices, but would that
help for files? I am using real block devices right now, but it would
be nice to also see a benefit for files in a file-system. Or maybe I
am mis-understanding this, and linux-aio can be used on files?
It could work with files with cache=none (though not qcow2 as now written).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
