From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Xen PVM: Strange lockups when running PostgreSQL load Date: Fri, 19 Oct 2012 10:33:11 +0200 Message-ID: <50811047.4080200@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> <507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com> <5081264002000078000A2841@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6728416877343941212==" Return-path: In-Reply-To: <5081264002000078000A2841@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) --===============6728416877343941212== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig686397E221017B7B45E4895C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig686397E221017B7B45E4895C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19.10.2012 10:06, Jan Beulich wrote: >>>> On 18.10.12 at 22:52, Stefan Bader wrot= e: >> Actually I begin to suspect that it could be possible that I just over= looked=20 >> the >> most obvious thing. Provoking question: are we sure we are on the same= page >> about the purpose of the spin_lock_flags variant of the pv lock ops=20 >> interface? >> >> I begin to suspect that it really is not for giving a chance to re-ena= ble >> interrupts. Just what it should be used for I am not clear. Anyway it = seems=20 >> all >> other places more or less ignore the flags and map themselves back to = an >> ignorant version of spinlock. >> Also I believe that the only high level function that would end up in = >> passing >> any flags, would be the spin_lock_irqsave one. And I am pretty sure th= at=20 >> this >> one will expect interrupts to stay disabled. >=20 > No - the only requirement here is that from the point on where > the lock is owned interrupt must remain disabled. Re-enabling > intermediately is quite okay (and used to be done by the > native kernel prior to the conversion to ticket locks iirc). Though it seems rather dangerous then. Don't remember the old code, but i= mo it always opens up a (even microscopic) window to unexpected interruptions. >=20 >> So I tried below approach and that seems to be surviving the previousl= y=20 >> breaking >> testcase for much longer than anything I tried before. >=20 > If that indeed fixes your problem, then (minus eventual problems > with the scope of the interrupts-enabled window) this rather > points at a bug in the users of the spinlock interfaces. I would be pragmatic here, none of the other current implementations seem= to re-enable interrupts and so this only affects xen pv. And how much really= is gained from enabling it compared to the risk of being affected by somethi= ng that nobody else will be? >=20 > Jan >=20 --------------enig686397E221017B7B45E4895C 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/ iQIcBAEBCgAGBQJQgRBIAAoJEOhnXe7L7s6jX74P/2FVJXa6TrkGNg+tACUfwktI +Ev8d/spqMqO2Y3tG8KghRB4yWLr1Vp5R9b7dKxf30nnG6eFoEYOuJ0+kSkgIlU7 vrVcxCjrSPrRXCNenGMMcKxRzu8BIY58Jr2NUWaOz5mHvpFKK5Y2Poecy0Sb7hFf vFDGkDcrdzQN7sV8f5R1haoDpNT5KlLtXo49M2Hiul6oMOlQrbgqo8OcBRggpU3V jSZGFHZfc/XaaAFR1GNDnQYIctFZt1HtFw8f2oZLw6GZFp1uLrcaCt6xkmHIjoTf 4vf8fxrGCSO/ZFKzFhQMQNv/TtWn+fhgj73V7qb/4of91Or/WXfN+NVkCduws0ZL 628b7HvbARTt5Wlas8WMZyIqbgQ5S0SZlrOMPJUKXgAM4ETwQqKCmH7h4hd285CL tPyqFifCRy8BT1Rp39WNfJ/IQ2Wbvg5RO/0y6TogHOI5b7haQuZjqDXUjANOsWZ+ teV06pEXq96dG+mGGegWWklfpWbUIpgtNzadBn7uQjABzgUh0KEzzipwZwuZpo3L S8shFOcZGjoqRMdMiWOoquofkQklj67wufXBBn4y8ln+pJ0MDlGJ33BJJDMiL+cK /qsyQhgcFEBR9svUnz7fdtSwtN5uyZ52WDBFh/H3kIOmVJaFyzByqnIBHi4PUH+N 25R89WMtF9wIxVZ8i691 =q4sc -----END PGP SIGNATURE----- --------------enig686397E221017B7B45E4895C-- --===============6728416877343941212== 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 --===============6728416877343941212==--