Re: [Qemu-discuss] 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