RE: [Xen-devel] RE: freezing when using GPLPV drivers (including Dom0)

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 
> >From: James Harper
> >Sent: Wednesday, December 31, 2008 10:46 AM
> >
> >I am suspecting that maybe the problem is disk starvation but I don't
> >quite understand why the lockup happens for so long. I'm also not
sure
> >why I'm only seeing the problem when using my GPLPV drivers - one
> >possibility is that the increased performance puts more load on the
> >storage system.
> >
> 
> Maybe you can check cycles spent on kernel thread/event handler
> in backend driver side. I'm not sure whether heavy communication
> between be/fe could disturb dom0 scheduler if care is not taken in
> current design. E.g. back kernel thread may eat too many cycles
> before giving up, or your GPLPV fe driver may issue too many events
> to break be side...
> 

I am running the restore again and monitoring using:
. xentop running in dom0
. arping to the DomU running from an external machine
. ping to Dom0 running from an external machine

With arping and ping running I have noticed that the freeze is not
always long enough to cause the TCP connections to time out - I was only
noticing the ones that were long enough.

During the freeze, xentop shows very low Dom0 and DomU CPU, arping stops
receiving replies to the arp requests, but the ping to Dom0 keeps going.
The freeze that just occurred was not long enough for me to tell if the
DomU xentop counters for network and disk were increasing or not.
(xentop keeps running, lending weight to the freeze only concerning
tasks that want to access the disk).

Is there a way under Linux of monitoring disk queue length? I am using
LVM on top of a low end HP 'Smart Array' (E200) running two RAID1
volumes using SATA disks.

Thanks

James

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