From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: questions about the number of pending requests that the host system can detect Date: Thu, 12 Aug 2010 11:21:15 -0700 Message-ID: <4C643B9B.1000308@goop.org> References: <4C6437C4.3040908@goop.org> 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: Yuehai Xu Cc: yuehai.xu@gmail.com, xen-devel@lists.xensource.com, yhxu@wayne.edu List-Id: xen-devel@lists.xenproject.org On 08/12/2010 11:18 AM, Yuehai Xu wrote: > On Thu, Aug 12, 2010 at 2:16 PM, Yuehai Xu wrote: >> On Thu, Aug 12, 2010 at 2:04 PM, Jeremy Fitzhardinge wrote: >>> On 08/11/2010 08:42 PM, Yuehai Xu wrote: >>>> However, the result turns out that my assumption is wrong. The number >>>> of pending requests, according to the trace of blktrace, is changing >>>> like this way: 9 8 7 6 5 4 3 2 1 1 1 2 3 4 5 4 3 2 1 1 1 2 3 4 5 6 7 8 >>>> 8 8..., just like a curve. >>>> >>>> I am puzzled about this weird result. Can anybody explain what has >>>> happened between domU and dom0 for this result? Does this result make >>>> sense? or I did something wrong to get this result. >>> If you're using a journalled filesystem in the guest, it will be need to >>> drain the IO queue periodically to control the write ordering. You should >>> also observe barrier writes in the blkfront stream. >>> >>> J >>> >> The file system I use in the guest system is ext3, which is a >> journaled file system. However, I don't quite understand what you said >> ".. control the write ordering" because the 10 processes running in >> the guest system all just send requests, there is no write request. >> What do you mean of "barrier writes" here? >> >> Thanks, >> Yuehai >> > I am sorry for the missing word, the requests sent by the 10 processes > in the guest system are all read requests. Even a pure read-only workload may generate writes for metadata unless you've turned it off. Is it a read-only mount? Do you have the noatime mount option? Is the device itself read-only? Still, it seems odd that it won't/can't keep the queue full of read requests. Unless its getting local cache hits? J