From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCqTx-000435-N6 for qemu-devel@nongnu.org; Thu, 21 Apr 2011 05:47:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCqTw-0000gx-IS for qemu-devel@nongnu.org; Thu, 21 Apr 2011 05:47:29 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:48089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCqTw-0000gs-G0 for qemu-devel@nongnu.org; Thu, 21 Apr 2011 05:47:28 -0400 Received: by vws17 with SMTP id 17so1362092vws.4 for ; Thu, 21 Apr 2011 02:47:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110421090935.GA5381@lst.de> References: <1303375391-26679-1-git-send-email-ronniesahlberg@gmail.com> <20110421085026.GA4817@lst.de> <20110421090935.GA5381@lst.de> Date: Thu, 21 Apr 2011 19:47:27 +1000 Message-ID: From: ronnie sahlberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] iSCSI support for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Christoph, I think you misread my test. My test is pure reading : sudo time dd if=3D/dev/sda of=3D/dev/null bs=3D1M There are no writes involved at all in this test, only a huge number of READ10 being sent to the target, or in the case of when using QEMU+openiscsi-mounted-lun sometimes being served out of the pagecache of the host. Since open-iscsi mounted LUNs by default perform so very poorly against libiscsi, I assume that there are very few blocks that are be served out of the cache of the host. This is based on that a block served out of cache would have significantly, many orders or magnitudes, lower access latency than a block that needs to be fetched across a 1GbE network. As open-iscsi performs so much poorly in this case compared to libiscsi, I just speculate that very few blocks are delivered by cache hits. I have absolutely no idea on why, QEMU+open-iscsi would perform so much better for a read-intensive workload like this when setting cache=3Dnone,aio=3Dnative. That is for the qemu developers to explain. Maybe doing READ10 through open-iscsi is very expensive? Maybe something else in the linux kernel makes reads very expensive unless you use "cache=3Dnone,aio=3Dnative"? Who knows? I have no idea, other than without using "cache=3Dnone,aio=3Dnative" QEMU performance for read intensive tasks are significantly slower than QEMU doing the exact same reads using libiscsi. I really don't care why QEMU+openiscsi performs so bad either. That is of very little interest to me. As long as libiscsi is not significantly worse than open-iscsi I care very little about why. regards ronnie sahlberg On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: >> In my patch, there are NO data integrity issues. >> Data is sent out on the wire immediately as the guest issues the write. >> Once the guest issues a flush call, the flush call will not terminate >> until the SYNCCACHE10 task has completed. > > No guest will even issue a cache flush, as we claim to be WCE=3D0 by defa= ult. > Now if you target has WCE=3D1 it will cache data internally, and your > iscsi initiator will never flush it out to disk. > > We only claim WCE=3D1 to the guest if cache=3Dwriteback or cache=3Dnone a= re > set. =A0So ignoring the issue of having a cache on the initiator side > you must implement stable writes for the default cache=3Dwritethrough > behaviour by either seeting the FUA bit on your writes, or doing > a cache flush after every write in case the target does not support FUA. > >