From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37271 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKvJw-0006sh-IT for qemu-devel@nongnu.org; Tue, 23 Nov 2010 11:02:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKvJj-0001tN-Jc for qemu-devel@nongnu.org; Tue, 23 Nov 2010 11:02:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKvJj-0001tD-C7 for qemu-devel@nongnu.org; Tue, 23 Nov 2010 11:02:03 -0500 Date: Tue, 23 Nov 2010 08:01:59 -0800 From: Chris Wright Message-ID: <20101123160159.GM31927@x200.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] KVM call minutes for Nov 23 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kvm@vger.kernel.org Cc: qemu-devel@nongnu.org qcow2 performance roadmap - What can be done to achieve near-raw image format performance? - some discussion points from Kevin on list http://lists.nongnu.org/archive/html/qemu-devel/2010-11/msg02126.html - please follow up on the list - some perf numbers (latest upstream qcow2 compared with qed) - qed is fully async, added unconditional flush to model qcow2 - http://wiki.qemu.org/Qcow2/PerformanceRoadmap - qcow2 not scaling as well - metadata handling still quite sync - sequential reads not scaling at all (a - only serialization point is two accesses to same block and need to allocate - template based backing file is common (esp. in cloud) - perf data suggests that data/table format dictates performance ceiling - barriers off on underlying fs, cache=writethrough - raw backing file (sparse) grows with basic tools like cp - suggestion: qed == qcow2 v3 - wouldn't support encryption and compression (Kevin won't do this) usb-ccid - concern about external library implementation - hard to add device features, enhancements, live migration protocol changes - external library - will resend patch to vcpu hard limits - will continue discussion on list 0.14 (release date, bug day, -rc planning, etc) - aiming for dec 15th - will send note out after call with release schedule 0.13.x - will connect with jforbes regarding -stable maintainance gPXE vs. iPXE - ipxe is new fork - ipxe looking more active (including original gpxe developers) - which is a better choice? - iPXE more active, gPXE stalled - some concern about where the community sits (gPXE has irc, bug reports, etc) - some concern about boot delay with iPXE - qemu not updating roms that frequently, next time we need to update, can evaluate - syslinux still using gPXE