WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Need help with fixing the Xen waitqueue feature

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Need help with fixing the Xen waitqueue feature
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Tue, 8 Nov 2011 22:20:24 +0100
Delivery-date: Tue, 08 Nov 2011 13:23:51 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1320787237; l=1138; s=domk; d=aepfle.de; h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=Y8EFbohvRpZvx75cdG1OEGivs3w=; b=iMrDJYvKNeeEGLopylcq7jPL3T4DSSLdR7BL2YbLvCCCUKoxuW4HGBoV2Eu3sQefCKb GKKa+3mpYZ8rD22jL/lL/j8bVP6ILqgQjjSn/tHCyjzDSW/JXOT9RDVGCZJrE+PnZHc2h 2q8CpDZy8sHFaffqwOzLSf7PX605t54OCaw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21.rev5535 (2011-07-01)
The patch 'mem_event: use wait queue when ring is full' I just sent out
makes use of the waitqueue feature. There are two issues I get with the
change applied:

I think I got the logic right, and in my testing vcpu->pause_count drops
to zero in p2m_mem_paging_resume(). But for some reason the vcpu does
not make progress after the first wakeup. In my debugging there is one
wakeup, the ring is still full, but further wakeups dont happen.
The fully decoded xentrace output may provide some hints about the
underlying issue. But its hard to get due to the second issue.

Another thing is that sometimes the host suddenly reboots without any
message. I think the reason for this is that a vcpu whose stack was put
aside and that was later resumed may find itself on another physical
cpu. And if that happens, wouldnt that invalidate some of the local
variables back in the callchain? If some of them point to the old
physical cpu, how could this be fixed? Perhaps a few "volatiles" are
needed in some places.

I will check wether pinning the guests vcpus to physical cpus actually
avoids the sudden reboots.

Olaf

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