From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Theurer Subject: Re: Re: poor domU VBD performance. Date: Wed, 30 Mar 2005 12:05:10 -0600 Message-ID: <424AEA56.20404@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: peter bier Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org peter bier wrote: >Ian Pratt cl.cam.ac.uk> writes: > > > >>>I'll check the xen block driver to see if there's anything >>>else that sticks out. >>> >>>Jens Axboe >>> >>> >>Jens, I'd really appreciate this. >> >>The blkfront/blkback drivers have rather evolved over time, and I don't >>think any of the core team fully understand the block-layer differences >>between 2.4 and 2.6. >> >>There's also some junk left in there from when the backend was in Xen >>itself back in the days of 1.2, though Vincent has prepared a patch to >>clean this up and also make 'refreshing' of vbd's work (for size >>changes), and also allow the blkfront driver to import whole disks >>rather than paritions. We had this functionality on 2.4, but lost it in >>the move to 2.6. >> >>My bet is that it's the 2.6 backend that is where the true perofrmance >>bug lies. Using a 2.6 domU blkfront talking to a 2.4 dom0 blkback seems >>to give good performance under a wide variety of circumstances. Using a >>2.6 dom0 is far more pernickety. I agree with Andrew that I suspect it's >>the work queue changes are biting us when we don't have many outstanding >>requests. >> >>Thanks, >>Ian >> >> >> > > >I have done my simple dd on hde1 with two different setting of readahead: >256 sectors and 512 sectors. > I added a counter and incremented every time blkback daemon was woken up and ran the read test in domU. With 32k and 320k request sizes (o_direct), I consistently got 200 wake ups/second. I expected 100/second, the same interval as the minimum svc cmt times I am seeing, but anyway, 200/sec is way to low for small request sizes. I think this confirms the latency issue. Not sure yet why it cannot wake up more frequently. -Andrew