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

[Yuehai Xu <yuehaixu@gmail.com>]

On Thu, Aug 12, 2010 at 2:21 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>  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?
>

The definition of my disk is: ['tap2:aio:/PATH/dom.img, hda1, w'], so,
I think it should not be read-only mount, and I don't set any specific
option for mount. The device itself should be read-write.


> Still, it seems odd that it won't/can't keep the queue full of read
> requests.  Unless its getting local cache hits?
>
>    J
>

I don't think the local cache would be hit because every time I did
the test, I drop the cache both in the guest and host OS. And, the
access pattern is stride read, it is impossible to hit the cache.

I am not sure whether there are write requests, even there are, I
think the number of write requests should be very small, will it
affect the I/O queue of guest or host? I don't think so. The common
sense should be that the I/O queue in the host system should be almost
full because tapdisk2 is async.

Thanks,
Yuehai