From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuehai Xu Subject: Re: questions about the number of pending requests that the host system can detect Date: Thu, 12 Aug 2010 14:36:20 -0400 Message-ID: References: <4C6437C4.3040908@goop.org> <4C643B9B.1000308@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C643B9B.1000308@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: yuehai.xu@gmail.com, xen-devel@lists.xensource.com, yhxu@wayne.edu List-Id: xen-devel@lists.xenproject.org On Thu, Aug 12, 2010 at 2:21 PM, Jeremy Fitzhardinge wrot= e: > =A0On 08/12/2010 11:18 AM, Yuehai Xu wrote: >> >> On Thu, Aug 12, 2010 at 2:16 PM, Yuehai Xu =A0wrote: >>> >>> On Thu, Aug 12, 2010 at 2:04 PM, Jeremy Fitzhardinge >>> =A0wrote: >>>> >>>> =A0On 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. =A0You >>>> should >>>> also observe barrier writes in the blkfront stream. >>>> >>>> =A0 =A0J >>>> >>> 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. =A0Is it a read-only mount? =A0Do you have the noat= ime > mount option? =A0Is 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. =A0Unless its getting local cache hits? > > =A0 =A0J > 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