[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] questions about the number of pending requests that the host system can detect



 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.

    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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.