[Qemu-devel] savevm too slow

[Qemu-devel] savevm too slow

[xuanmao_001]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Hi, qemuers:

I found that the guest disk file cache mode will affect to the time of savevm.

the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can, less than 10 seconds.

here is the example I use virsh:
@cache with writeback:
#the first snapshot
real    0m21.904s
user    0m0.006s
sys     0m0.008s

#the secondary snapshot
real    2m11.624s
user    0m0.013s
sys     0m0.008s

@cache with unsafe:
#the first snapshot
real    0m0.730s
user    0m0.006s
sys     0m0.005s

#the secondary snapshot
real    0m1.296s
user    0m0.002s
sys     0m0.008s

so, what the difference between them when using different cache.

the other question: when I change the buffer size #define IO_BUF_SIZE 32768 
to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.


thanks.



xuanmao_001

[-- Attachment #2: Type: text/html, Size: 2428 bytes --]

Re: [Qemu-devel] savevm too slow

[Kevin Wolf]

Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> Hi, qemuers:
>  
> I found that the guest disk file cache mode will affect to the time of savevm.
>  
> the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> less than 10 seconds.
>  
> here is the example I use virsh:
> @cache with writeback:
> #the first snapshot
> real    0m21.904s
> user    0m0.006s
> sys     0m0.008s
>  
> #the secondary snapshot
> real    2m11.624s
> user    0m0.013s
> sys     0m0.008s
>  
> @cache with unsafe:
> #the first snapshot
> real    0m0.730s
> user    0m0.006s
> sys     0m0.005s
>  
> #the secondary snapshot
> real    0m1.296s
> user    0m0.002s
> sys     0m0.008s

I sent patches that should eliminate the difference between the first
and second snapshot at least.

> so, what the difference between them when using different cache.

cache=unsafe ignores any flush requests. It's possible that there is
potential for optimisation with cache=writeback, i.e. it sends flush
requests that aren't necessary in fact. This is something that I haven't
checked yet.

> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.

Is this for cache=unsafe as well?

Juan, any specific reason for using 32k? I think it would be better to
have a multiple of the qcow2 cluster size, otherwise we get COW for the
empty part of newly allocated clusters. If we can't make it dynamic,
using at least fixed 64k to match the qcow2 default would probably
improve things a bit.

Kevin

Re: [Qemu-devel] savevm too slow

[xuanmao_001]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

>> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
>> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.

> Is this for cache=unsafe as well?

> Juan, any specific reason for using 32k? I think it would be better to
> have a multiple of the qcow2 cluster size, otherwise we get COW for the
> empty part of newly allocated clusters. If we can't make it dynamic,
> using at least fixed 64k to match the qcow2 default would probably
> improve things a bit.

with cache=writeback.  Is there any risk for setting cache=writeback with IO_BUF_SIZE 1M ?




xuanmao_001

From: Kevin Wolf
Date: 2013-09-06 18:38
To: xuanmao_001
CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
Subject: Re: savevm too slow
Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> Hi, qemuers:
>  
> I found that the guest disk file cache mode will affect to the time of savevm.
>  
> the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> less than 10 seconds.
>  
> here is the example I use virsh:
> @cache with writeback:
> #the first snapshot
> real    0m21.904s
> user    0m0.006s
> sys     0m0.008s
>  
> #the secondary snapshot
> real    2m11.624s
> user    0m0.013s
> sys     0m0.008s
>  
> @cache with unsafe:
> #the first snapshot
> real    0m0.730s
> user    0m0.006s
> sys     0m0.005s
>  
> #the secondary snapshot
> real    0m1.296s
> user    0m0.002s
> sys     0m0.008s

I sent patches that should eliminate the difference between the first
and second snapshot at least.

> so, what the difference between them when using different cache.

cache=unsafe ignores any flush requests. It's possible that there is
potential for optimisation with cache=writeback, i.e. it sends flush
requests that aren't necessary in fact. This is something that I haven't
checked yet.

> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.

Is this for cache=unsafe as well?

Juan, any specific reason for using 32k? I think it would be better to
have a multiple of the qcow2 cluster size, otherwise we get COW for the
empty part of newly allocated clusters. If we can't make it dynamic,
using at least fixed 64k to match the qcow2 default would probably
improve things a bit.

Kevin

[-- Attachment #2: Type: text/html, Size: 6615 bytes --]

Re: [Qemu-devel] savevm too slow

[Kevin Wolf]

Am 09.09.2013 um 03:57 hat xuanmao_001 geschrieben:
> >> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> >> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
>  
> > Is this for cache=unsafe as well?
>  
> > Juan, any specific reason for using 32k? I think it would be better to
> > have a multiple of the qcow2 cluster size, otherwise we get COW for the
> > empty part of newly allocated clusters. If we can't make it dynamic,
> > using at least fixed 64k to match the qcow2 default would probably
> > improve things a bit.
>  
> with cache=writeback.  Is there any risk for setting cache=writeback with
> IO_BUF_SIZE 1M ?

No. Using a larger buffer size should be safe.

Kevin

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> xuanmao_001
>  
> From: Kevin Wolf
> Date: 2013-09-06 18:38
> To: xuanmao_001
> CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
> Subject: Re: savevm too slow
> Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> > Hi, qemuers:
> >  
> >
>  I found that the guest disk file cache mode will affect to the time of savevm.
> >  
> > the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> > less than 10 seconds.
> >  
> > here is the example I use virsh:
> > @cache with writeback:
> > #the first snapshot
> > real    0m21.904s
> > user    0m0.006s
> > sys     0m0.008s
> >  
> > #the secondary snapshot
> > real    2m11.624s
> > user    0m0.013s
> > sys     0m0.008s
> >  
> > @cache with unsafe:
> > #the first snapshot
> > real    0m0.730s
> > user    0m0.006s
> > sys     0m0.005s
> >  
> > #the secondary snapshot
> > real    0m1.296s
> > user    0m0.002s
> > sys     0m0.008s
>  
> I sent patches that should eliminate the difference between the first
> and second snapshot at least.
>  
> > so, what the difference between them when using different cache.
>  
> cache=unsafe ignores any flush requests. It's possible that there is
> potential for optimisation with cache=writeback, i.e. it sends flush
> requests that aren't necessary in fact. This is something that I haven't
> checked yet.
>  
> > the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> > to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
>  
> Is this for cache=unsafe as well?
>  
> Juan, any specific reason for using 32k? I think it would be better to
> have a multiple of the qcow2 cluster size, otherwise we get COW for the
> empty part of newly allocated clusters. If we can't make it dynamic,
> using at least fixed 64k to match the qcow2 default would probably
> improve things a bit.
>  
> Kevin

Re: [Qemu-devel] savevm too slow

[xuanmao_001]

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

> I sent patches that should eliminate the difference between the first
> and second snapshot at least.

where I can find the patches that can eliminate the difference between the first
and second snapshot ? Does they fit qemu-kvm-1.0,1 ?




xuanmao_001

From: Kevin Wolf
Date: 2013-09-09 16:35
To: xuanmao_001
CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
Subject: Re: Re: savevm too slow
Am 09.09.2013 um 03:57 hat xuanmao_001 geschrieben:
> >> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> >> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
>  
> > Is this for cache=unsafe as well?
>  
> > Juan, any specific reason for using 32k? I think it would be better to
> > have a multiple of the qcow2 cluster size, otherwise we get COW for the
> > empty part of newly allocated clusters. If we can't make it dynamic,
> > using at least fixed 64k to match the qcow2 default would probably
> > improve things a bit.
>  
> with cache=writeback.  Is there any risk for setting cache=writeback with
> IO_BUF_SIZE 1M ?

No. Using a larger buffer size should be safe.

Kevin

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> xuanmao_001
>  
> From: Kevin Wolf
> Date: 2013-09-06 18:38
> To: xuanmao_001
> CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
> Subject: Re: savevm too slow
> Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> > Hi, qemuers:
> >  
> >
>  I found that the guest disk file cache mode will affect to the time of savevm.
> >  
> > the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> > less than 10 seconds.
> >  
> > here is the example I use virsh:
> > @cache with writeback:
> > #the first snapshot
> > real    0m21.904s
> > user    0m0.006s
> > sys     0m0.008s
> >  
> > #the secondary snapshot
> > real    2m11.624s
> > user    0m0.013s
> > sys     0m0.008s
> >  
> > @cache with unsafe:
> > #the first snapshot
> > real    0m0.730s
> > user    0m0.006s
> > sys     0m0.005s
> >  
> > #the secondary snapshot
> > real    0m1.296s
> > user    0m0.002s
> > sys     0m0.008s
>  
> I sent patches that should eliminate the difference between the first
> and second snapshot at least.
>  
> > so, what the difference between them when using different cache.
>  
> cache=unsafe ignores any flush requests. It's possible that there is
> potential for optimisation with cache=writeback, i.e. it sends flush
> requests that aren't necessary in fact. This is something that I haven't
> checked yet.
>  
> > the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> > to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
>  
> Is this for cache=unsafe as well?
>  
> Juan, any specific reason for using 32k? I think it would be better to
> have a multiple of the qcow2 cluster size, otherwise we get COW for the
> empty part of newly allocated clusters. If we can't make it dynamic,
> using at least fixed 64k to match the qcow2 default would probably
> improve things a bit.
>  
> Kevin

[-- Attachment #2: Type: text/html, Size: 8720 bytes --]

Re: [Qemu-devel] savevm too slow

[Kevin Wolf]

Am 09.09.2013 um 10:47 hat xuanmao_001 geschrieben:
> > I sent patches that should eliminate the difference between the first
> > and second snapshot at least.
>  
> where I can find the patches that can
> eliminate the difference between the first
> and second snapshot ? Does they fit qemu-kvm-1.0,1 ?

I sent them to you on Friday, the first email has the following subject
line:

[PATCH 0/2] qcow2: Discard VM state in active L1 after creating snapshot

This patch series is for current git master, and chances are that it
would work for qemu 1.6 as well. It will most likely not apply for qemu
1.0, which is almost two years old.

Kevin

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> xuanmao_001
>  
> From: Kevin Wolf
> Date: 2013-09-09 16:35
> To: xuanmao_001
> CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
> Subject: Re: Re: savevm too slow
> Am 09.09.2013 um 03:57 hat xuanmao_001 geschrieben:
> > >> the other question: when I change the buffer size #
> define IO_BUF_SIZE 32768
> > >> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
> >  
> > > Is this for cache=unsafe as well?
> >  
> > > Juan, any specific reason for using 32k? I think it would be better to
> > > have a multiple of the qcow2 cluster size, otherwise we get COW for the
> > > empty part of newly allocated clusters. If we can't make it dynamic,
> > > using at least fixed 64k to match the qcow2 default would probably
> > > improve things a bit.
> >  
> > with cache=writeback.  Is there any risk for setting cache=writeback with
> > IO_BUF_SIZE 1M ?
>  
> No. Using a larger buffer size should be safe.
>  
> Kevin
>  
> >
>  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> > xuanmao_001
> >  
> > From: Kevin Wolf
> > Date: 2013-09-06 18:38
> > To: xuanmao_001
> > CC: qemu-discuss; qemu-devel; quintela; stefanha; mreitz
> > Subject: Re: savevm too slow
> > Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> > > Hi, qemuers:
> > >  
> > >
> >
>   I found that the guest disk file cache mode will affect to the time of savevm.
> > >  
> > >
>  the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> > > less than 10 seconds.
> > >  
> > > here is the example I use virsh:
> > > @cache with writeback:
> > > #the first snapshot
> > > real    0m21.904s
> > > user    0m0.006s
> > > sys     0m0.008s
> > >  
> > > #the secondary snapshot
> > > real    2m11.624s
> > > user    0m0.013s
> > > sys     0m0.008s
> > >  
> > > @cache with unsafe:
> > > #the first snapshot
> > > real    0m0.730s
> > > user    0m0.006s
> > > sys     0m0.005s
> > >  
> > > #the secondary snapshot
> > > real    0m1.296s
> > > user    0m0.002s
> > > sys     0m0.008s
> >  
> > I sent patches that should eliminate the difference between the first
> > and second snapshot at least.
> >  
> > > so, what the difference between them when using different cache.
> >  
> > cache=unsafe ignores any flush requests. It's possible that there is
> > potential for optimisation with cache=writeback, i.e. it sends flush
> > requests that aren't necessary in fact. This is something that I haven't
> > checked yet.
> >  
> > > the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> > > to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
> >  
> > Is this for cache=unsafe as well?
> >  
> > Juan, any specific reason for using 32k? I think it would be better to
> > have a multiple of the qcow2 cluster size, otherwise we get COW for the
> > empty part of newly allocated clusters. If we can't make it dynamic,
> > using at least fixed 64k to match the qcow2 default would probably
> > improve things a bit.
> >  
> > Kevin