From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyzZP-0001M8-Ea for qemu-devel@nongnu.org; Mon, 23 Jun 2014 04:25:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WyzZH-0005tK-Mb for qemu-devel@nongnu.org; Mon, 23 Jun 2014 04:25:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyzZH-0005sj-8L for qemu-devel@nongnu.org; Mon, 23 Jun 2014 04:25:35 -0400 Date: Mon, 23 Jun 2014 16:25:10 +0800 From: Stefan Hajnoczi Message-ID: <20140623082510.GA9640@stefanha-thinkpad.redhat.com> References: <35adc553.340a.146c679d395.Coremail.magazine.lihuiba@163.com> <20140623030120.GB4638@T430.nay.redhat.com> <36859ae2.53b9.146c6b7aeab.Coremail.magazine.lihuiba@163.com> <20140623032237.GC4638@T430.nay.redhat.com> <6db7bace.5114.146c761fa69.Coremail.magazine.lihuiba@163.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <6db7bace.5114.146c761fa69.Coremail.magazine.lihuiba@163.com> Subject: Re: [Qemu-devel] extremely low IOPS performance of QCOW2 image format on an SSD RAID1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: lihuiba Cc: kwolf@redhat.com, qiujian@meituan.com, Fam Zheng , qemu-devel@nongnu.org, mengcong@meituan.com --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 23, 2014 at 02:20:25PM +0800, lihuiba wrote: > I think I have found the reason: > There's a cache in qemu that accelerates the transform of virtual LBA to cluster offset of qcow2 image. > The cache has a fixed size of 16x8192=128k in my configuration, which corresponds to a 8GB (128K*64KB) > mapping size. So when the "working set" of fio exceeds 8GB, the transform wil be degraded to reading > external table, and the performances goes extremely low. Can you confirm that making L2_CACHE_SIZE much bigger solves the problem? You also have the optional of specifying the cluster size when creating the qcow2 image file. A larger cluster size reduces the amount of metadata overhead and therefore increases cache hits. Stefan --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTp+RmAAoJEJykq7OBq3PI/3QIALCAHqKbnJgDZ9W8iUI6SmQM ROb877EdH+tHzcz+0QQxBX/35X08TL2bZKsnNG8dx62+85JiJ07ftSgnpbmpGJrM ZAW4UmnZQiQknIDkd3QAnex5YqgqoESHsAmOrsc06hsWF6YIOmWiWcWcAD7NJV7B i6r3WbQORwWhuHlSrOviNQFlAS1MV8cv9ZWHLxS0G/R7et2DcZZmN34unKTkAQVS LYG2q+N1MSoPl72sEC5HmfZdLZPCOm+JrfVnz13uN8NG0GDjVqq+pPePpnRLFJwB P4a+PjL18poaQI/MOmxdCdvBlx8FoxQMzzId+U+HLYrvJDly2+jxhOrXrvaNi5o= =PzaL -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2--