On 04/04/2013 04:36 PM, Abel Gordon wrote:
> We just posted a technical report that describes the design and evaluation
> of the work we did to improve virtual net/block I/O scalability and
> performance based on vhost and hosting multiple KVM guests.
> You can find the report here: http://goo.gl/R
Abel Gordon writes:
> qemu-devel-bounces+abelg=il.ibm@nongnu.org wrote on 03/03/2013 11:35:27
> AM:
>
> We just posted a technical report that describes the design and evaluation
> of the work we did to improve virtual net/block I/O scalability and
> performance based on vhost and hosting mul
qemu-devel-bounces+abelg=il.ibm@nongnu.org wrote on 03/03/2013 11:35:27
AM:
> > Also, I wonder if you have time to do a presentation/discussion session
> > so we can get the ball rolling and more people exposed to your
approach.
> > There is a weekly QEMU Community Call which we can use as the
Hi Stefan,
This is excellent ! Thank you very much :-)
Cheers
On 03/13/2013 04:21 PM, Stefan Hajnoczi wrote:
> On Thu, Feb 21, 2013 at 9:11 AM, Stefan Hajnoczi wrote:
>> On Mon, Feb 18, 2013 at 7:19 PM, Loic Dachary wrote:
>>> I recently tried to figure out the best and easiest ways to increas
On Thu, Feb 21, 2013 at 9:11 AM, Stefan Hajnoczi wrote:
> On Mon, Feb 18, 2013 at 7:19 PM, Loic Dachary wrote:
>> I recently tried to figure out the best and easiest ways to increase block
>> I/O performances with qemu. Not being a qemu expert, I expected to find a
>> few optimization tricks. M
On Sun, Mar 03, 2013 at 11:35:27AM +0200, Abel Gordon wrote:
>
>
> Stefan Hajnoczi wrote on 01/03/2013 12:54:54 PM:
>
> > On Thu, Feb 28, 2013 at 08:20:08PM +0200, Abel Gordon wrote:
> > > Stefan Hajnoczi wrote on 28/02/2013 04:43:04 PM:
> > > > I think extending and tuning the existing mecha
On Sun, Mar 3, 2013 at 10:35 AM, Abel Gordon wrote:
>
>
> Stefan Hajnoczi wrote on 01/03/2013 12:54:54 PM:
>
>> On Thu, Feb 28, 2013 at 08:20:08PM +0200, Abel Gordon wrote:
>> > Stefan Hajnoczi wrote on 28/02/2013 04:43:04 PM:
>> > > I think extending and tuning the existing mechanisms is the w
Stefan Hajnoczi wrote on 01/03/2013 12:54:54 PM:
> On Thu, Feb 28, 2013 at 08:20:08PM +0200, Abel Gordon wrote:
> > Stefan Hajnoczi wrote on 28/02/2013 04:43:04 PM:
> > > I think extending and tuning the existing mechanisms is the way to
go.
> > > I don't see obvious advantages other than red
On Thu, Feb 28, 2013 at 08:20:08PM +0200, Abel Gordon wrote:
> Stefan Hajnoczi wrote on 28/02/2013 04:43:04 PM:
> > I think extending and tuning the existing mechanisms is the way to go.
> > I don't see obvious advantages other than reducing context switches.
>
> Maybe it is worth checking...
> W
Stefan Hajnoczi wrote on 28/02/2013 04:43:04 PM:
> > I see your point, but the shared-process only needs access to
> > the virtio ring/buffers (not necessary the entire memory of
> > all the guests), the network sockets and image files opened by
> > all the qemu user-space process. So, if you hav
On Wed, Feb 27, 2013 at 05:25:49PM +0200, Abel Gordon wrote:
>
>
> Stefan Hajnoczi wrote on 26/02/2013 06:45:30 PM:
>
>
> > > But is this significantly different than any other security bug in the
> > > host,
> > > qemu, kvm? If you perform the I/O virtualization in a separate (not
> > > q
Stefan Hajnoczi wrote on 26/02/2013 06:45:30 PM:
> > But is this significantly different than any other security bug in the
> > host,
> > qemu, kvm? If you perform the I/O virtualization in a separate (not
> > qemu)
> > process, you have a significantly smaller, self-contained and bounded
>
Stefan Hajnoczi wrote on 26/02/2013 06:45:30 PM:
> > But is this significantly different than any other security bug in the
> > host,
> > qemu, kvm? If you perform the I/O virtualization in a separate (not
> > qemu)
> > process, you have a significantly smaller, self-contained and bounded
On Mon, Feb 25, 2013 at 08:45:58PM +0200, Abel Gordon wrote:
>
>
> Stefan Hajnoczi wrote on wrote on 25/02/2013 02:50:56
> PM:
> > You also create a
> > privileged thread that has access to all guests on the host - a security
> > bug here compromises all guests. This can be fine for private
> >
Stefan Hajnoczi wrote on wrote on 25/02/2013 02:50:56
PM:
> > However, I am concerned dataplane may not solve the scalability
> > problem because QEMU will be still running 1 thread
> > per VCPU and 1 per virtual device to handle I/O for each VM.
> > Assuming we run N VMs with 1 VCPU and 1 virt
On Mon, Feb 25, 2013 at 10:48:47AM +0200, Abel Gordon wrote:
> Stefan Hajnoczi wrote on 21/02/2013 10:11:12 AM:
>
> > From: Stefan Hajnoczi
> > To: Loic Dachary ,
> > Cc: qemu-devel
> > Date: 21/02/2013 10:11 AM
> > Subject: Re: [Qemu-devel] Block I/O o
Stefan Hajnoczi wrote on 21/02/2013 10:11:12 AM:
> From: Stefan Hajnoczi
> To: Loic Dachary ,
> Cc: qemu-devel
> Date: 21/02/2013 10:11 AM
> Subject: Re: [Qemu-devel] Block I/O optimizations
> Sent by: qemu-devel-bounces+abelg=il.ibm@nongnu.org
>
> On Mon, Feb 1
Hi Stefan,
Thanks a lot, I'm looking forward to it ;-)
Cheers
On 02/21/2013 09:11 AM, Stefan Hajnoczi wrote:
> On Mon, Feb 18, 2013 at 7:19 PM, Loic Dachary wrote:
>> I recently tried to figure out the best and easiest ways to increase block
>> I/O performances with qemu. Not being a qemu expe
On Mon, Feb 18, 2013 at 7:19 PM, Loic Dachary wrote:
> I recently tried to figure out the best and easiest ways to increase block
> I/O performances with qemu. Not being a qemu expert, I expected to find a few
> optimization tricks. Much to my surprise, it appears that there are many
> signific
Hi,
I recently tried to figure out the best and easiest ways to increase block I/O
performances with qemu. Not being a qemu expert, I expected to find a few
optimization tricks. Much to my surprise, it appears that there are many
significant improvements being worked on. This is excellent news
20 matches
Mail list logo
