Re: [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter
From: Avi Kivity
Date: Wed Mar 17 2010 - 12:41:00 EST
On 03/17/2010 06:22 PM, Avi Kivity wrote:
Also, if my guest kernel issues (say) three small writes, one at the
start
of the disk, one in the middle, one at the end, and then does a
flush, can
virtio really express this as one non-contiguous O_DIRECT write (the
three
components of which can be reordered by the elevator with respect to one
another) rather than three distinct O_DIRECT writes which can't be
permuted?
Can qemu issue a write like that? cache=writeback + flush allows this
to be
optimised by the block layer in the normal way.
Guest side virtio will send this as three requests followed by a
flush. Qemu will issue these as three distinct requests and then
flush. The requests are marked, as Christoph says, in a way that
limits their reorderability, and perhaps if we fix these two problems
performance will improve.
Something that comes to mind is merging of flush requests. If N
guests issue one write and one flush each, we should issue N writes
and just one flush - a flush for the disk applies to all volumes on
that disk.
Chris, can you carry out an experiment? Write a program that pwrite()s
a byte to a file at the same location repeatedly, with the file opened
using O_SYNC. Measure the write rate, and run blktrace on the host to
see what the disk (/dev/sda, not the volume) sees. Should be a (write,
flush, write, flush) per pwrite pattern or similar (for writing the data
and a journal block, perhaps even three writes will be needed).
Then scale this across multiple guests, measure and trace again. If
we're lucky, the flushes will be coalesced, if not, we need to work on it.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/