From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcWZS-0000FI-IY for qemu-devel@nongnu.org; Wed, 15 May 2013 03:56:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcWZP-0004zT-NY for qemu-devel@nongnu.org; Wed, 15 May 2013 03:56:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcWZP-0004zP-FW for qemu-devel@nongnu.org; Wed, 15 May 2013 03:56:19 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4F7uIIK022557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 May 2013 03:56:18 -0400 Date: Wed, 15 May 2013 09:56:15 +0200 From: Stefan Hajnoczi Message-ID: <20130515075615.GA17320@stefanha-thinkpad.muc.redhat.com> References: <1368498390-20738-1-git-send-email-famz@redhat.com> <20130514082253.GG3632@stefanha-thinkpad.redhat.com> <20130515034636.GA27583@fam-laptop.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130515034636.GA27583@fam-laptop.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 00/11] curl: fix curl read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: famz@redhat.com, qemu-devel@nongnu.org, kwolf@redhat.com, jcody@redhat.com On Wed, May 15, 2013 at 11:46:36AM +0800, Fam Zheng wrote: > On Tue, 05/14 10:22, Stefan Hajnoczi wrote: > > On Tue, May 14, 2013 at 10:26:19AM +0800, Fam Zheng wrote: > > > - CURLDataCache holds the user data read from libcurl, it is in a list > > > ordered by access, the used cache is moved to list head on access, so > > > the tail element is freed first. BDRVCURLState.cache_quota is the > > > threshold to start freeing cache. > > > > Can you explain the need for a cache? > > > > The guest kernel already does readahead if it wants to. It can be tuned > > from inside the guest if performance doesn't meet expectations. The > > block/curl.c-specific cache cannot be tuned from the guest. > > The guest may not do well on this. E.g. GRUB sends sequencial 2KB aio > requests loading the kernel of several MBs. This may make the curl > performs horribly to boot a guest from http served iso. Good point, this is probably the reason. Once the kernel is running the requests should be bigger but during boot the BIOS and bootloader may issue very small requests. Stefan