public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] Avoid fragment virtio-blk transfers by copying
Date: Wed, 25 Jun 2008 11:28:46 -0500	[thread overview]
Message-ID: <4862723E.5010002@us.ibm.com> (raw)
In-Reply-To: <48622193.6080401@qumranet.com>

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).

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.

>   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.

Regards,

Anthony Liguori


  parent reply	other threads:[~2008-06-25 16:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24 18:16 [PATCH] Avoid fragment virtio-blk transfers by copying Anthony Liguori
2008-06-24 19:47 ` Marcelo Tosatti
2008-06-25 10:44 ` Avi Kivity
2008-06-25 15:55   ` Marcelo Tosatti
2008-06-29  9:56     ` Avi Kivity
2008-06-25 16:28   ` Anthony Liguori [this message]
2008-06-29 10:01     ` 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=4862723E.5010002@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=avi@qumranet.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox