Xen devel - Mar 2011 - RE: [GIT/PATCH 0/5] Re: unfair servicing of DomU vbd requests

Hi James.
 
I go through the patch, since all its changes happens inside
__xen_evtchn_do_upcall(),
so I apply the patch into my 2.6.31.kernel by manual. (I was failed to merge a
usable,
2.6.38dom0, since quite a lot branch needed, such as blkback, netback)
 
But still, the blue screen shows up. Log attached.
Is the timeout better than before?
 
Beside, I think I need find some to examine my harddisk.  

 
> Subject: FW: [GIT/PATCH 0/5] Re: [Xen-devel] unfair servicing of DomU vbd
requests
> Date: Fri, 4 Mar 2011 09:26:44 +1100
> From: james.harper@bendigoit.com.au
> To: tinnycloud@hotmail.com
> 
> Ian has posted some patches to xen-devel. Can you apply them to your Dom0
kernel and see if they fix your i/o servicing problem?
> 
> As I understand it, without this patch Dom0 will service the lowest event
channel first, so if there is always an io request on the lower channel the
higher channels will never get serviced. A bad disk would aggravate this
situation but isn''t really the cause of it.
> 
> James
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Friday, 4 March 2011 04:10
> > To: Keir Fraser
> > Cc: James Harper; xen devel; Konrad Rzeszutek Wilk; Jeremy
Fitzhardinge
> > Subject: [GIT/PATCH 0/5] Re: [Xen-devel] unfair servicing of DomU vbd
requests
> > 
> > On Thu, 2011-03-03 at 08:30 +0000, Keir Fraser wrote:
> > > Without the round-robin servicing, unfairness to the point of
starvation is
> > > a distinct possibility.
> > 
> > Indeed. The following is a forward port of these patches from
> > 2.6.18-xen.hg:
> > * 324:7fe1c6d02a2b
> > * 325:b2768401db94
> > * 988:c88a02a22a05
> > * 990:427276ac595d
> > * 991:9ba6d9f3fbc0
> > 
> > Hopefully I didn''t miss any.
> > 
> > The switch in pvops from "l1"/"l2" naming
convention to "word"/"bit"
> > made the conflict resolution a bit prone to thinkos but hopefully I
> > didn''t b0rk it too badly. Review with that in mind greatly
appreciated.
> > 
> > boots a dom0 + a pv guest.
> > 
> > Pull request on top of konrad/stable/irq.cleanup:
> > 
> > The following changes since commit
c5ae07bb307b658c8458f29ca77d237aec0f9327:
> > Ian Campbell (1):
> > xen: events: remove dom0 specific xen_create_msi_irq
> > 
> > are available in the git repository at:
> > 
> > git://xenbits.xen.org/people/ianc/linux-2.6.git irq-fairness
> > 
> > Ian Campbell (1):
> > xen: events: Make last processed event channel a per-cpu variable.
> > 
> > Keir Fraser (3):
> > xen: events: Clean up round-robin evtchn scan.
> > xen: events: Make round-robin scan fairer by snapshotting each l2 word
> > xen: events: Remove redundant clear of l2i at end of round-robin loop
> > 
> > Scott Rixner (1):
> > xen: events: Process event channels notifications in round-robin
order.
> > 
> > drivers/xen/events.c | 80
+++++++++++++++++++++++++++++++++++++++++++++----
> > -
> > 1 files changed, 72 insertions(+), 8 deletions(-)
> > 
> > 
> > 
> > Ian.
> > 
> > 
> > 
> 
 		 	   		  


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

> 
> I go through the patch, since all its changes happens inside
> __xen_evtchn_do_upcall(),
> so I apply the patch into my 2.6.31.kernel by manual. (I was failed to
merge a
> usable,
> 2.6.38dom0, since quite a lot branch needed, such as blkback, netback)
> 
> But still, the blue screen shows up. Log attached.
> Is the timeout better than before?
> 
> Beside, I think I need find some to examine my harddisk.
> 
Looking at the resets, every time you see "Completing in-flight srb ...
with status SRB_STATUS_BUS_RESET" you should subsequently see
"discarding reset shadow" indicating that Dom0 completed the request
also (even though we already told Windows that the reset was done). You
can see this after the first HwScsiResetBus, but not after any
subsequent resets, indicating that even after 72 seconds xenvbd hasn''t
processed any further vbd requests. The last two requests confirm this
as no requests have been placed on the ring which must be full. That
says to me that either there is a bug in GPLPV, Dom0 still isn''t
servicing IO requests fairly, or you do have a problem with your disk.

If it''s a disk problem, you should be getting errors under Linux at
some
level. If the drivers support SMART you can query their health that way
too.

James


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

Thanks James.
Patch applied and crash log attached.
 
I''ve been able to merge the code accrording to Ian post on
http://lists.colo.xensource.com/archives/html/xen-devel/2011-03/msg00225.html
 
But unfortunately, the starting of 24HVMS become rather slow, and 
after some period of time, whole Host stop responding.
It takes some more time to find what is going on.

 
> Subject: RE: [GIT/PATCH 0/5] Re: [Xen-devel] unfair servicing of DomU vbd
requests
> Date: Tue, 8 Mar 2011 22:04:42 +1100
> From: james.harper@bendigoit.com.au
> To: tinnycloud@hotmail.com
> 
> > 
> > Hi James.
> > 
> > I go through the patch, since all its changes happens inside
> > __xen_evtchn_do_upcall(),
> > so I apply the patch into my 2.6.31.kernel by manual. (I was failed to
> merge a
> > usable,
> > 2.6.38dom0, since quite a lot branch needed, such as blkback, netback)
> > 
> > But still, the blue screen shows up. Log attached.
> > Is the timeout better than before?
> > 
> > Beside, I think I need find some to examine my harddisk.
> > 
> 
> Not really important, but the ASSERT you are seeing in dump mode happens
> when xenvbd finally does complete the request, but obviously dump mode
> knows nothing about it. The following patch initialises the reset flag
> on all requests in dump mode so that when they do come back they are
> just discarded. Crash dump should now complete (although slowly in your
> case!):
> 
> diff -r 4722ecc909c3 xenvbd/xenvbd_scsiport.c
> --- a/xenvbd/xenvbd_scsiport.c Thu Mar 03 23:21:10 2011 +1100
> +++ b/xenvbd/xenvbd_scsiport.c Tue Mar 08 22:01:57 2011 +1100
> @@ -278,6 +278,12 @@
> {
> xvdd->shadows[i].req.id = i;
> put_shadow_on_freelist(xvdd, &xvdd->shadows[i]);
> + if (dump_mode)
> + {
> + /* set reset = TRUE to pick up in-flight requests when dump
> mode kicked in */
> + /* do it after put_shadow_on_freelist because that resets the
> reset flag */
> + xvdd->shadows[i].reset = TRUE;
> + }
> }
> }
> 
> James
 		 	   		  


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