From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcWQO-0005bo-Ut for qemu-devel@nongnu.org; Wed, 15 May 2013 03:47:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcWQL-00023D-Pw for qemu-devel@nongnu.org; Wed, 15 May 2013 03:47:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcWQL-000237-Hh for qemu-devel@nongnu.org; Wed, 15 May 2013 03:46:57 -0400 Date: Wed, 15 May 2013 09:46:53 +0200 From: Stefan Hajnoczi Message-ID: <20130515074653.GA16991@stefanha-thinkpad.muc.redhat.com> References: <1367568009-4900-1-git-send-email-famz@redhat.com> <20130509064111.GC1074@stefanha-thinkpad.redhat.com> <20130509065650.GA5031@fam-laptop.nay.redhat.com> <20130509151620.GB26728@stefanha-thinkpad.redhat.com> <20130515032929.GA23662@fam-laptop.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130515032929.GA23662@fam-laptop.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH] curl: fix curl read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , kwolf@redhat.com, qemu-devel@nongnu.org On Wed, May 15, 2013 at 11:29:29AM +0800, Fam Zheng wrote: > On Thu, 05/09 17:16, Stefan Hajnoczi wrote: > > On Thu, May 09, 2013 at 02:56:50PM +0800, Fam Zheng wrote: > > > On Thu, 05/09 08:41, Stefan Hajnoczi wrote: > > > > On Fri, May 03, 2013 at 04:00:09PM +0800, Fam Zheng wrote: > > > > > + cache = curl_find_cache(s, aio_base, aio_bytes); > > > > > + if (cache) { > > > > > + curl_complete_io(s, acb, cache); > > > > > + return; > > > > > } > > > > > > > > What is the point of the cache? Can you split it into a separate patch? > > > > > > The cache is for prefetch. Data is fetched by 256k chunks using libcurl > > > and stored in cache to fill future io request, reducing overall http > > > request overhead. > > > > That sounds like a performance optimization which is not part of fixing > > broken block/curl.c :). > > > > I didn't invent it here. Read ahead is already in curl.c, (see > BDRVCURLState.readahead_size). I don't think it's time to remove it here > either, but rename to a better name should be OK. What do you think? Yes, that's true. Although I'm not a fan of readahead I guess it's already implemented. > BTW please keep me CC'ed when reply so that I can notice it better. Please check the headers that your email client is sending: Mail-Followup-To: Stefan Hajnoczi , Stefan Hajnoczi , kwolf@redhat.com, qemu-devel@nongnu.org Stefan