From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: xen/arm: Domain not fully destroyed when using credit2 Date: Thu, 2 Feb 2017 13:01:52 +0100 Message-ID: <1486036912.18830.33.camel@citrix.com> References: <1485263974.32103.61.camel@citrix.com> <1485265231.32103.65.camel@citrix.com> <1485267419.32103.71.camel@citrix.com> <1485342610.32103.96.camel@citrix.com> <0c19de52-e7f5-b97a-ec31-41b4284add32@arm.com> <1485360009.32103.125.camel@citrix.com> <6ea5c07c-aaed-933a-f7fd-dd56d23c0b04@arm.com> <20170201182126.cu6qn4wcrxaylbr3@citrix.com> <5893249D0200007800136139@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4221694529959796423==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZG5X-0000di-CU for xen-devel@lists.xenproject.org; Thu, 02 Feb 2017 12:02:07 +0000 In-Reply-To: <5893249D0200007800136139@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , Julien Grall , Wei Liu Cc: Stefano Stabellini , George Dunlap , AndrewCooper , Tim Deegan , xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org --===============4221694529959796423== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-1Ip0R0P7A2ieoS88bTYp" --=-1Ip0R0P7A2ieoS88bTYp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-02-02 at 04:22 -0700, Jan Beulich wrote: > On 01.02.17 at 19:21, wrote: > > On Tue, Jan 31, 2017 at 04:30:50PM +0000, Julien Grall wrote: > > > Yeah, even the tiny RCU code is quite complex :/. I've looked at=20 > > > our RCUcode and noticed there is a link in the header to [1]. > > >=20 > > > It seems to be a documentation about the RCU code we used. From > > > my > > > understanding of the "RCU Implementations", the authors are > > > expecting a > > > timer to kick periodically pCPU and check if there is some RCU > > > work pending. > > Worth checking all the RCU docs in Linux (Documentation/RCU). > >=20 > > I think there are descriptions about idle or no-tick variants. > It surely is worth, but bearing in mind that, as said before, Linux RCUs are indeed more powerful than what we have, but also much much much much more complex than what we probably need. And (for Julien), perhaps it's me, but I don't think I see references or hints at using a timer in the docs you linked, nor on other RCU doc material. As a matter of fact, I agree with Jan, i.e., > Isn't all we need an rcu_idle_{enter,exit}() implementation (and of > course calls to them placed where needed)? >=20 This is what I think we're missing. And, AFAIUI, it's sort of similar to what Stefano (I think) was saying, that a CPU going idle is a step toward grace period, because rcu critical sections can't occur on it. As per what Julien said about softirqs (which also looks right to me), this is how Linux handles the issue: http://lxr.free-electrons.com/source/kernel/rcu/tree.c#L733 /** * rcu_idle_enter - inform RCU that current CPU is entering idle * * Enter idle mode, in other words, -leave- the mode in which RCU * read-side critical sections can occur. (Though RCU read-side * critical sections can occur in irq handlers in idle, a possibility * handled by irq_enter() and irq_exit().) */ So we may also need rcu_irq_enter() and rcu_irq_exit(). Regards, Dario --=C2=A0 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-1Ip0R0P7A2ieoS88bTYp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYkx+wAAoJEBZCeImluHPuGWEQAOClCFiYmLtdCA/QyzPVQNOo 5vcu+YG2q3qomObz1W8g/yuOEKCnO+5/YYwkOveEJjt/+0c0hp+mQmh3f3X4Y0wo Ye8WCRJUwM/urN6UWy6TL0S7i/ILG8LKBNwEVqRVGA3JGPczuvC/nsNbQ1UJHVzx x2yeUbVnwLRSIikdmQ97/EiyD/uRpyQzD3NcIucj+Kcj25PmIrH9rylHjmnCVfRZ TjNWy7fLz6oEK+HGfIXqdC7JTOpEiW7xO6qLXOBhfw3dZS3Jm/pYZ62fRRjY52Sn 4+VrciU5zMr18i9F7WAfav49qSeK39BWO2t8fkh5bg3WLKU5ecF4ObLPQPsg2Wig aHmkE3j5wc6bPvKZtaIX6hQ4oaoR8NX8N9qAYCzIt9R7cm7oCc7HOUD+7UTu5LEq d1kup4nS+JYY8mBU+cc5QWkAZMnL/T9PKUzkUAcgs+prPrUGKIjrMsURmpUVMJbQ /18MHKgYYOSh5Pwpr1AtHbOg8C7B6YumXU1XQ9oM/typRC8VYPpsx5U8f6ibe7Hq LG1MlSXW0H8Sz1VNxBoitfrip3SguFQ9zh8fqlw+tCjzjDoBN+fU5vclMCV6Eg3x 38wzxgg0qAJqFqIqH+WyaoUl+kX3a2IWTMb/ZQrKuqa/TEnaZnc0HLoXfezfTZRe Su3iFm6jhVqGyykMpp/f =pcDh -----END PGP SIGNATURE----- --=-1Ip0R0P7A2ieoS88bTYp-- --===============4221694529959796423== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4221694529959796423==--