[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: freezing when using GPLPV drivers (including Dom0)
> > >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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |