Re: questions about the number of pending requests that the host system can detect

[Jeremy Fitzhardinge <jeremy@goop.org>]

  On 08/12/2010 11:18 AM, Yuehai Xu wrote:
> On Thu, Aug 12, 2010 at 2:16 PM, Yuehai Xu<yuehaixu@gmail.com>  wrote:
>> On Thu, Aug 12, 2010 at 2:04 PM, Jeremy Fitzhardinge<jeremy@goop.org>  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