From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Xen PVM: Strange lockups when running PostgreSQL load Date: Thu, 18 Oct 2012 14:43:16 +0200 Message-ID: <507FF964.9090009@canonical.com> References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com> <507EB27D.8050308@citrix.com> <1350482118.2460.74.camel@zakaz.uk.xensource.com> <507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com> <507FC51102000078000A235E@nat28.tlf.novell.com> <507FC71502000078000A236C@nat28.tlf.novell.com> <507FB1E1.8080700@canonical.com> <1350546483.28188.25.camel@dagon.hellion.org.uk> <507FD7DE.2010209@canonical.com> <507FFA5102000078000A250D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7077398237862403059==" Return-path: In-Reply-To: <507FFA5102000078000A250D@nat28.tlf.novell.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: Jan Beulich Cc: Andrew Cooper , Konrad Rzeszutek Wilk , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7077398237862403059== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB9EE666080330C7C1DAF7137" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB9EE666080330C7C1DAF7137 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18.10.2012 12:47, Jan Beulich wrote: >>>> On 18.10.12 at 12:20, Stefan Bader wrot= e: >> On 18.10.2012 09:48, Ian Campbell wrote: >>> spinning_lock() returns the old lock which the caller is expected to >>> remember and replace via unspinning_lock() -- it effectively implemen= ts >>> a stack of locks which are being waited on. xen_spin_lock_slow (the o= nly >>> caller0 appears to do this correctly from a brief inspection. >> >> Yes, just *when* can there be a stack of locks (spinlocks). The poll_i= rq >> hypercall seems to be an active (in the sense of not preemting to anot= her=20 >> task) >> process. How could there be a situation that another lock (on the same= cpu=20 >> is tried to be taken). >=20 > Obviously when this is an acquire not disabling interrupts, and > an interrupt comes in while in the poll hypercall (or about to go > there, or just having come back from one). >=20 > Jan >=20 Obviously. ;) Ok, so my thinking there was ok and its one level deep max.= At some point staring at things I start question my sanity. A wild thinking would be whether in that case the interrupted spinlock ma= y miss a wakeup forever when the unlocker only can check for the toplevel. Hm, b= ut that should be easy to rule out by just adding an error to spin_unlock_slow wh= en it fails to find anything... --------------enigB9EE666080330C7C1DAF7137 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 Mozilla - http://www.enigmail.net/ iQIcBAEBCgAGBQJQf/lkAAoJEOhnXe7L7s6jYAgP/jIqqQosyyCp/wdPBclVSws3 qK4wLJYOdJWuiWMNMSxgob2eXmWRdThh4MvGM73PH54QOsoynd0aafd8aOAiJ0Hu GPvRRdIPjh3zFK78WAcIr6NAwaYwNwrIecbvqtBzjjVDgFuDImCqq9dmRwfWekAW NF422nKmcHQYTEL2lSDs/vqjF27rsNrtZP6cISStxnu70YXBzaSextob/jBbGkd6 GSJovcirPG0yG1piYJYBO99neUKpibqEWOQOqZPFa0jpzCsRlpPkIvLf4vyrIZsK zuPKp1gGtHj5WBhNlrHhLN9Jp90qBjL5ZV4nmC3LUwMax4zayOXU4zu0rkbJC5RP KigYCYEL1E068nxAF80jzm88H6aGGGy09gRWxYxVGBJby8q7pDmP0FxMbopMfGBF bCAEj8Wie7pXz1JfrXJRXfAxj0QAnutWbfKNESCgs6/yg3wzDIPgtYLGLNPHnQD9 XlII3jf4Zb+8tfi0Q0d2/wOyj8mwwwqOXk27mGiUNTU4HNHaunOvCssKJJLe4hyS 4cN7BShxXmLpNjm4iXI9T2xxrnpeuwRA+yg36yEM7GqwCioYnO6Q8se6d56bSf5X ciU+UGMOQxCjjUBVLBeseIFr8ke+KC+sCsCvJVBAKkGXOHgmYaBjfvUcfHu4jpAR BlFKUuadDSPm8uG5dp4N =Mvbw -----END PGP SIGNATURE----- --------------enigB9EE666080330C7C1DAF7137-- --===============7077398237862403059== 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 --===============7077398237862403059==--