From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIql8-0006Z4-LG for qemu-devel@nongnu.org; Sun, 08 Sep 2013 21:59:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIql1-0002RP-A8 for qemu-devel@nongnu.org; Sun, 08 Sep 2013 21:59:22 -0400 Date: Mon, 9 Sep 2013 09:57:39 +0800 From: xuanmao_001 References: <2013090609312026502832@163.com>, <20130906103837.GH2588@dhcp-200-207.str.redhat.com> Mime-Version: 1.0 Message-ID: <201309090957395153945@163.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart442061468574_=----" Subject: Re: [Qemu-devel] savevm too slow Reply-To: xuanmao_001 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: mreitz , quintela , qemu-devel , stefanha , qemu-discuss This is a multi-part message in MIME format. ------=_001_NextPart442061468574_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Pj4gdGhlIG90aGVyIHF1ZXN0aW9uOiB3aGVuIEkgY2hhbmdlIHRoZSBidWZmZXIgc2l6ZSAjZGVm aW5lIElPX0JVRl9TSVpFIDMyNzY4DQo+PiB0byAjZGVmaW5lIElPX0JVRl9TSVpFICgxICogMTAy NCAqIDEwMjQpLCB0aGUgc2F2ZXZtIGlzIG1vcmUgcXVpY2tseS4NCg0KPiBJcyB0aGlzIGZvciBj YWNoZT11bnNhZmUgYXMgd2VsbD8NCg0KPiBKdWFuLCBhbnkgc3BlY2lmaWMgcmVhc29uIGZvciB1 c2luZyAzMms/IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvDQo+IGhhdmUgYSBtdWx0aXBs ZSBvZiB0aGUgcWNvdzIgY2x1c3RlciBzaXplLCBvdGhlcndpc2Ugd2UgZ2V0IENPVyBmb3IgdGhl DQo+IGVtcHR5IHBhcnQgb2YgbmV3bHkgYWxsb2NhdGVkIGNsdXN0ZXJzLiBJZiB3ZSBjYW4ndCBt YWtlIGl0IGR5bmFtaWMsDQo+IHVzaW5nIGF0IGxlYXN0IGZpeGVkIDY0ayB0byBtYXRjaCB0aGUg cWNvdzIgZGVmYXVsdCB3b3VsZCBwcm9iYWJseQ0KPiBpbXByb3ZlIHRoaW5ncyBhIGJpdC4NCg0K d2l0aCBjYWNoZT13cml0ZWJhY2suICBJcyB0aGVyZSBhbnkgcmlzayBmb3Igc2V0dGluZyBjYWNo ZT13cml0ZWJhY2sgd2l0aCBJT19CVUZfU0laRSAxTSA/DQoNCg0KDQoNCnh1YW5tYW9fMDAxDQoN CkZyb206IEtldmluIFdvbGYNCkRhdGU6IDIwMTMtMDktMDYgMTg6MzgNClRvOiB4dWFubWFvXzAw MQ0KQ0M6IHFlbXUtZGlzY3VzczsgcWVtdS1kZXZlbDsgcXVpbnRlbGE7IHN0ZWZhbmhhOyBtcmVp dHoNClN1YmplY3Q6IFJlOiBzYXZldm0gdG9vIHNsb3cNCkFtIDA2LjA5LjIwMTMgdW0gMDM6MzEg aGF0IHh1YW5tYW9fMDAxIGdlc2NocmllYmVuOg0KPiBIaSwgcWVtdWVyczoNCj4gIA0KPiBJIGZv dW5kIHRoYXQgdGhlIGd1ZXN0IGRpc2sgZmlsZSBjYWNoZSBtb2RlIHdpbGwgYWZmZWN0IHRvIHRo ZSB0aW1lIG9mIHNhdmV2bS4NCj4gIA0KPiB0aGUgY2FjaGUgJ3dyaXRlYmFjaycgdG9vIHNsb3cu IGJ1dCB0aGUgY2FjaGUgJ3Vuc2FmZScgaXMgYXMgZmFzdCBhcyBpdCBjYW4sDQo+IGxlc3MgdGhh biAxMCBzZWNvbmRzLg0KPiAgDQo+IGhlcmUgaXMgdGhlIGV4YW1wbGUgSSB1c2Ugdmlyc2g6DQo+ IEBjYWNoZSB3aXRoIHdyaXRlYmFjazoNCj4gI3RoZSBmaXJzdCBzbmFwc2hvdA0KPiByZWFsICAg IDBtMjEuOTA0cw0KPiB1c2VyICAgIDBtMC4wMDZzDQo+IHN5cyAgICAgMG0wLjAwOHMNCj4gIA0K PiAjdGhlIHNlY29uZGFyeSBzbmFwc2hvdA0KPiByZWFsICAgIDJtMTEuNjI0cw0KPiB1c2VyICAg IDBtMC4wMTNzDQo+IHN5cyAgICAgMG0wLjAwOHMNCj4gIA0KPiBAY2FjaGUgd2l0aCB1bnNhZmU6 DQo+ICN0aGUgZmlyc3Qgc25hcHNob3QNCj4gcmVhbCAgICAwbTAuNzMwcw0KPiB1c2VyICAgIDBt MC4wMDZzDQo+IHN5cyAgICAgMG0wLjAwNXMNCj4gIA0KPiAjdGhlIHNlY29uZGFyeSBzbmFwc2hv dA0KPiByZWFsICAgIDBtMS4yOTZzDQo+IHVzZXIgICAgMG0wLjAwMnMNCj4gc3lzICAgICAwbTAu MDA4cw0KDQpJIHNlbnQgcGF0Y2hlcyB0aGF0IHNob3VsZCBlbGltaW5hdGUgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGUgZmlyc3QNCmFuZCBzZWNvbmQgc25hcHNob3QgYXQgbGVhc3QuDQoNCj4g c28sIHdoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVtIHdoZW4gdXNpbmcgZGlmZmVyZW50 IGNhY2hlLg0KDQpjYWNoZT11bnNhZmUgaWdub3JlcyBhbnkgZmx1c2ggcmVxdWVzdHMuIEl0J3Mg cG9zc2libGUgdGhhdCB0aGVyZSBpcw0KcG90ZW50aWFsIGZvciBvcHRpbWlzYXRpb24gd2l0aCBj YWNoZT13cml0ZWJhY2ssIGkuZS4gaXQgc2VuZHMgZmx1c2gNCnJlcXVlc3RzIHRoYXQgYXJlbid0 IG5lY2Vzc2FyeSBpbiBmYWN0LiBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IEkgaGF2ZW4ndA0KY2hl Y2tlZCB5ZXQuDQoNCj4gdGhlIG90aGVyIHF1ZXN0aW9uOiB3aGVuIEkgY2hhbmdlIHRoZSBidWZm ZXIgc2l6ZSAjZGVmaW5lIElPX0JVRl9TSVpFIDMyNzY4DQo+IHRvICNkZWZpbmUgSU9fQlVGX1NJ WkUgKDEgKiAxMDI0ICogMTAyNCksIHRoZSBzYXZldm0gaXMgbW9yZSBxdWlja2x5Lg0KDQpJcyB0 aGlzIGZvciBjYWNoZT11bnNhZmUgYXMgd2VsbD8NCg0KSnVhbiwgYW55IHNwZWNpZmljIHJlYXNv biBmb3IgdXNpbmcgMzJrPyBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0bw0KaGF2ZSBhIG11 bHRpcGxlIG9mIHRoZSBxY293MiBjbHVzdGVyIHNpemUsIG90aGVyd2lzZSB3ZSBnZXQgQ09XIGZv ciB0aGUNCmVtcHR5IHBhcnQgb2YgbmV3bHkgYWxsb2NhdGVkIGNsdXN0ZXJzLiBJZiB3ZSBjYW4n dCBtYWtlIGl0IGR5bmFtaWMsDQp1c2luZyBhdCBsZWFzdCBmaXhlZCA2NGsgdG8gbWF0Y2ggdGhl IHFjb3cyIGRlZmF1bHQgd291bGQgcHJvYmFibHkNCmltcHJvdmUgdGhpbmdzIGEgYml0Lg0KDQpL ZXZpbg== ------=_001_NextPart442061468574_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
>> the other question: when I cha= nge the buffer size #define IO_BUF_SIZE 3276= 8
>> to #define IO_BUF_SIZE (1 * 10= 24 * 1024), the savevm is more quickly.=
 
> Is this for cache=3Dunsafe as well?
 
>=20 Juan, any specific reason for using 32k?&nbs= p;I think it would be better to
>=20 have a multiple of the qcow2 cluster si= ze, otherwise we get COW for the
>=20 empty part of newly allocated clusters. If&n= bsp;we can't make it dynamic,
>=20 using at least fixed 64k to match the&n= bsp;qcow2 default would probably
> improve things a bit.
 
with cache=3Dwriteback.  Is there any risk for setting cache=3Dw= riteback=20 with IO_BUF_SIZE 1M ?
 
xuanmao_001
 
From: Kevin Wolf<= /DIV>
Date: 2013-09-06 18:38
CC: qemu-discu= ss;=20 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 f= ile cache mode will affect to the time&= nbsp;of savevm.
>  
> the cache 'writeback' too slow. bu= t the cache 'unsafe' is as fast as = ;it can,
> less than 10 seconds.
>  
> here is the example I use vir= sh:
> @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 th= e difference between the first
and second snapshot at least.
 
> so, what the difference between th= em when using different cache.
 
cache=3Dunsafe ignores any flush requests. I= t's possible that there is
potential for optimisation with cache=3Dwriteback= , 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&= nbsp;the buffer size #define IO_BUF_SIZE 32768
> to #define IO_BUF_SIZE (1 * 1024&n= bsp;* 1024), the savevm is more quickly.
 
Is this for cache=3Dunsafe as well?
 
Juan, any specific reason for using 32k= ? I think it would be better to
have a multiple of the qcow2 cluster&nb= sp;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
------=_001_NextPart442061468574_=------