From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJjSA-0004Z6-Ir for qemu-devel@nongnu.org; Thu, 25 Jun 2009 03:33:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJjS6-0004TS-0w for qemu-devel@nongnu.org; Thu, 25 Jun 2009 03:33:02 -0400 Received: from [199.232.76.173] (port=33508 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJjS5-0004TP-Sf for qemu-devel@nongnu.org; Thu, 25 Jun 2009 03:32:57 -0400 Received: from mx20.gnu.org ([199.232.41.8]:55171) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJjS5-0008WL-97 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 03:32:57 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJjS3-000746-UA for qemu-devel@nongnu.org; Thu, 25 Jun 2009 03:32:56 -0400 Message-ID: <4A4327E0.2020509@redhat.com> Date: Thu, 25 Jun 2009 09:31:44 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] block-raw: Make cache=off default again References: <1245669483-7076-1-git-send-email-kwolf@redhat.com> <20090622113524.GA13583@lst.de> <4A3F6EA3.2010303@redhat.com> <4A3F7139.20401@redhat.com> <4A3F79C0.6000804@redhat.com> <4A3F7B87.6000605@redhat.com> <4A3F7E32.8090905@redhat.com> <20090623103019.GA14437@shareable.org> <4A40C085.8050701@redhat.com> <20090624212330.GC14121@shareable.org> In-Reply-To: <20090624212330.GC14121@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Avi Kivity , Christoph Hellwig Jamie Lokier schrieb: > Kevin Wolf wrote: >> Jamie Lokier schrieb: >>> Kevin Wolf wrote: >>>> What happens with virtio I still need to understand. Obviously, as soon >>>> as virtio decides to fall back to 4k requests, performance becomes >>>> terrible. >>> Does emulating a disk with 4k sector size instead of 512 bytes help this? >> I just changed the virtio_blk code to always do the >> blk_queue_hardsect_size with 4096, didn't change the behaviour. > > You need quite a bit more than that to emulate a 4k sector size disk. > There's the ATA/SCSI ID pages to update, and the special 512-bit > offset tricky thing. Okay, then I'll just admit that I know too little about the Linux block layer. I'll gladly try any patch (and hopefully understand it then), but for doing it myself I think it would take me a lot of time experimenting and still not knowing if I'm doing it right. >> I'm not sure if I have mentioned it in this thread: We have found that >> it helps to use the deadline elevator instead of cfq in either the host >> or the guest. I would accept this if it would only help when it's >> changed in the guest (after all, I don't know the Linux block layer very >> well), but I certainly don't understand how the host elevator could >> change the guest request sizes - and noone else on the internal mailing >> lists had an explanation either. > > The host elevator will certainly affect the timing of I/O requests, > which it receives from the guest, and it will also affect how requests > are merged to make larger requests. > > So it's not surprising that the host elevator changes the sizes of > request sizes when they reach the host disk. > > It shouldn't change the size of requests inside the guest, _before_ > they reach the host. Yeah, this is exactly what I was thinking, too. However, in reality it _does_ influence the guest request sizes, for whatever reason (maybe again something timing related?). I put debug code into both the qemu virtio-blk implementation and the guest kernel module and they both see lots of 4k requests when the host uses cfg and much larger requests when it uses deadline. Kevin