From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuSWN-0004bf-IM for qemu-devel@nongnu.org; Tue, 10 Jun 2014 16:20:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuSWE-0006BN-5T for qemu-devel@nongnu.org; Tue, 10 Jun 2014 16:19:51 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:38423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuSWD-0006Aw-Tz for qemu-devel@nongnu.org; Tue, 10 Jun 2014 16:19:42 -0400 Received: by mail-wg0-f47.google.com with SMTP id k14so6952890wgh.6 for ; Tue, 10 Jun 2014 13:19:40 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53976857.2080508@redhat.com> Date: Tue, 10 Jun 2014 22:19:35 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <53961C5B.9020201@us.ibm.com> <20140610014038.GA11308@T430.nay.redhat.com> <539754EC.3070600@us.ibm.com> In-Reply-To: <539754EC.3070600@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] dataplane performance on s390 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Karl Rister , Fam Zheng Cc: qemu-devel@nongnu.org, stefanha@redhat.com Il 10/06/2014 20:56, Karl Rister ha scritto: > On 06/09/2014 08:40 PM, Fam Zheng wrote: >> On Mon, 06/09 15:43, Karl Rister wrote: >>> Hi All >>> >>> I was asked by our development team to do a performance sniff test of >>> the >>> latest dataplane code on s390 and compare it against qemu.git. Here >>> is a >>> brief description of the configuration, the testing done, and then the >>> results. >>> >>> Configuration: >>> >>> Host: 26 CPU LPAR, 64GB, 8 zFCP adapters >>> Guest: 4 VCPU, 1GB, 128 virtio block devices >>> >>> Each virtio block device maps to a dm-multipath device in the host >>> with 8 >>> paths. Multipath is configured with the service-time policy. All block >>> devices are configured to use the deadline IO scheduler. >>> >>> Test: >>> >>> FIO is used to run 4 scenarios: sequential read, sequential write, >>> random >>> read, and random write. Sequential scenarios use a 128KB request >>> size and >>> random scenarios us a 8KB request size. Each scenario is run with an >>> increasing number of jobs, from 1 to 128 (powers of 2). Each job is >>> bound >>> to an individual file on an ext3 file system on a virtio device and uses >>> O_DIRECT, libaio, and iodepth=1. Each test is run three times for 2 >>> minutes >>> each, the first iteration (a warmup) is thrown out and the next two >>> iterations are averaged together. >>> >>> Results: >>> >>> Baseline: qemu.git 93f94f9018229f146ed6bbe9e5ff72d67e4bd7ab >>> >>> Dataplane: bdrv_set_aio_context 0ab50cde71aa27f39b8a3ea4766ff82671adb2a4 >> >> Hi Karl, >> >> Thanks for the results. >> >> The throughput differences look minimal, where is the bandwidth >> saturated in >> these tests? And why use iodepth=1, not more? > > Hi Fam > > Based on previously collected data, the configuration is hitting > saturation at the following points: > > Sequential Read: 128 jobs > Sequential Write: 32 jobs > Random Read: 64 jobs > Random Write: saturation not reached > > The iodepth=1 configuration is a somewhat arbitrary choice that is only > limited by machine run time, I could certainly run higher loads and at > times I do. What is the overall throughput in iops and MB/s, on both baremetal and virt? Paolo