This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] questions about the number of pending requests that the

To: Yuehai Xu <yuehaixu@xxxxxxxxx>
Subject: Re: [Xen-devel] questions about the number of pending requests that the host system can detect
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 12 Aug 2010 11:21:15 -0700
Cc: yuehai.xu@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, yhxu@xxxxxxxxx
Delivery-date: Thu, 12 Aug 2010 11:27:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTin5L=qOGAH_oQDXnF9eaodnOxz6f6z6HAxEu6d-@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=3d=+J2WNbBM5rLu_MfpjA_3OXhm8qOkCf_sLg@xxxxxxxxxxxxxx> <4C6437C4.3040908@xxxxxxxx> <AANLkTimwpt8xFAt5Njw5V8+5qUFs2WTpWqUSacS_+3Qa@xxxxxxxxxxxxxx> <AANLkTin5L=qOGAH_oQDXnF9eaodnOxz6f6z6HAxEu6d-@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1
 On 08/12/2010 11:18 AM, Yuehai Xu wrote:
On Thu, Aug 12, 2010 at 2:16 PM, Yuehai Xu<yuehaixu@xxxxxxxxx>  wrote:
On Thu, Aug 12, 2010 at 2:04 PM, Jeremy Fitzhardinge<jeremy@xxxxxxxx>  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.


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?


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?


Xen-devel mailing list