Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
A major source of performance loss for virtio-blk has been the fact
that we
split transfers into multiple requests. This is particularly
harmful if you
have striped storage beneath your virtual machine.
This patch copies the request data into a single contiguous buffer
to ensure
that we don't split requests. This improves performance from about
80 MB/sec
to about 155 MB/sec with my fibre channel link. 185 MB/sec is what
we get on
native so this gets us pretty darn close.
If the guest issues a request for a terabyte of memory, the host will
try to allocate it and drop to swap/oom.
An unprivileged user should not be able to OOM the kernel by simply
doing memory allocations. Likewise, while it will start swapping,
that should primarily effect the application allocating memory
(although yes, it's consuming IO bandwidth to do the swapping).
Without the rss controller, there's no reason that this should happen.
Linux will swap not-recently-used pages, whether belonging to the
application or not.
As long as we properly handle memory allocation failures, it's my
contention that allowing a guest to allocate unbound amounts of
virtual memory is safe.
It isn't: suppose you oom the machine, even if you have proper
overcommit enabled (which is unlikely) there's no guarantee that the
allocating guest will get the ENOMEM. Some other application might, and
it's unreasonable to expect it to recover.
Consider also a machine with no swap. You've carefully allocated 1G to
a VM, and here it goes and allocates the rest, ooming your fine-tuned host.
So we need to either fragment beyond some size, or to avoid copying
and thus the need for allocation.
As Marcelo mentioned, there are very practical limitations on how much
memory can be in-flight on any given queue. A malicious guest could
construct a nasty queue that basically pointed to all of the guest
physical memory for each entry in the queue but that's still a bound
size.
It's bounded, but by a really huge number (4GB x ring length x number of
disks).
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
