From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Strange PVM spinlock case revisited Date: Wed, 13 Feb 2013 12:31:15 +0100 Message-ID: <511B7983.7000907@canonical.com> References: <51151ABF.1070007@canonical.com> <1360603744.20449.74.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9037532320681636710==" Return-path: In-Reply-To: <1360603744.20449.74.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Andrew Cooper , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============9037532320681636710== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC95BF4D59164A7C52A3588D0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC95BF4D59164A7C52A3588D0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11.02.2013 18:29, Ian Campbell wrote: > An interesting hack^Wexperiment might be to make xen_poll_irq use a > timeout and see if that unwedges things -- this would help confirm that= > the issue is on nested wakeup. >=20 So I did go forward and replaced xen_poll_irq by xen_poll_irq_timeout and= it did get rid of the hang. Though I think there is a big taint there. There was= only one other user of poll_irq_timeout in the kernel code. And that uses= "jiffies + *HZ". But when I look at the Xen side in do_poll, tha= t looks like it is using timeout in a absolute "ns since boot" (of hv/dom0) way. = Not sure how that ever can work. The ns since boot in the guest clearly is al= ways behind the host (and jiffies isn't ns either). Effectively I likely got rid of any wait time in the hypervisor and back = to mostly spinning. Which matches the experience that the test run never get= s stuck waiting for a timeout. That maybe proves the stacking is an issue but als= o is likely a bit too aggressive in not having any... :/ I will try to think of some better way. Not sure the thinking is realisti= c but maybe that could happen: xen_spin_lock_slow(a) ... enables irq and upcalls are pending upcall processing wants lock b xen_spin_lock_slow(b) --- just before replacing lock_spinners --- xen_spin_unlock_slow(a= ) finds other vcpu, trig= gers IRQ lock b is top spinner going into poll_irq poll_irq returns lock a gets restored so maybe no spinners on b dropping out to xen_spin_lock unlock of b not finding= any spinners lock b acquired That way the irq for lock a maybe get lost... --------------enigC95BF4D59164A7C52A3588D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIbBAEBCgAGBQJRG3mDAAoJEOhnXe7L7s6jxTUP9jdsIAZn6RKxBHaW3Y0DHGvz 2x4ZJ1jGktG7RzbqUcYoaU0PqOXgW/bpbdYAwx/Yz17/Y3CI0cR47DbhjJLsGCJt kfb417yW35wN2AJs2pVeGOTETkBHE3vOLNipv8/fevYCg/8MaokIowDKuHbETY4c aQOVqTLJ31zlCP04CxKfTmv5kw79hw3zF+VlEpFyHBivBU7sCfg1d9SlOrcyJseQ HQXtss6McUOcFpNcOo1uoV6q+ODsIAhvicEp1WPgHzkctYhRG4m5nYgRaaemly9e AaP0ONNIwdXcmPIZUSK2Q1qj1FvaAH9HRFvo07sYy4N2+uWHQOZWTXo5MWFUNdzh Q9Vdpstx8SfsRXuByLdxML3QEjaVhbQ7uZt0J/4pp8z79d5jQT4hMgGS/+ENVsd1 vaBBvYBOX1/zbEIYNu2HkjNQpntvGKC6UPMkBNXZBc97eZIM/3RkKqatJknvbjDA nsES9ks4szwqtnl2IacHV2EzGIbWmfdABaJzfJ9NTph2LHBVOa6HWXhKjfVbY5Kk 4lBrpV+jq+ExG1Qb/QWSuiHuLhPelMscKv29eyaPuTwEmV62AYQTHhRJIQMIwIFr kKmZ+kPWv65PvfnYA+NkAfC9MmgzzT6+7EBeEK5hLNiqTS6MRrLn+4yfNY9tTpZZ Ir7jIgVBD5D5g0DMieY= =wnhp -----END PGP SIGNATURE----- --------------enigC95BF4D59164A7C52A3588D0-- --===============9037532320681636710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9037532320681636710==--