From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 21/24] ARM: vITS: handle INVALL command Date: Tue, 6 Dec 2016 23:39:55 +0100 Message-ID: <1481063995.3445.125.camel@citrix.com> References: <20160928182457.12433-1-andre.przywara@arm.com> <0fce93d4-605b-78b9-9146-b4d65eb4e86a@arm.com> <4a8bb842-bac5-942f-ca84-d223f43ab50b@arm.com> <1481059976.3445.98.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7025477464600051415==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEOPa-0006bW-77 for xen-devel@lists.xenproject.org; Tue, 06 Dec 2016 22:40:34 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Stefano Stabellini Cc: Vijay Kilari , Steve Capper , Andre Przywara , george.dunlap@citrix.com, Julien Grall , xen-devel List-Id: xen-devel@lists.xenproject.org --===============7025477464600051415== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-j7Io+EBtg11GKXdiSH5u" --=-j7Io+EBtg11GKXdiSH5u Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-12-06 at 13:53 -0800, Stefano Stabellini wrote: > On Tue, 6 Dec 2016, Dario Faggioli wrote: > > Sorry if I can't be more useful than this for now. :-/ >=20 > We don't need scheduler support to implement interrupt migration. The > question was much simpler than that: moving a vCPU with interrupts > assigned to it is slower than moving a vCPU without interrupts > assigned > to it. You could say that the slowness is directly proportional do > the > number of interrupts assigned to the vCPU. Does the scheduler know > that? > Or blindly moves vCPUs around? Also see below. >=20 Ah, ok, it is indeed a simpler question than I thought! :-) Answer: no, the scheduler does not use the information of how many or what interrupts are being routed to a vCPU in any way. Just for the sake of correctness and precision, it does not "blindly moves vCPUs around", as in, it follows some criteria for deciding whether or not to move a vCPU, and if yes, where to, but among those criteria, there is no trace of anything related to routed interrupts. Let me also add that the criteria are scheduler specific, so they're different, e.g., between Credit and Credit2. Starting considering routed interrupt as a migration criteria in Credit would be rather difficult. Credit use a 'best effort' approach for migrating vCPUs, which is hard to augment. Starting considering routed interrupt as a migration criteria in Credit2 would be much easier. Credit2's load balancer is specifically designed for being extendible with things like that. It would require some thinking, though, in order to figure out how important this particular aspect would be, wrt others that are considered. E.g., if I have pCPU 0 loaded at 75% and pCPU 1 loaded at 25%, vCPU A has a lot of routed interrupts, and moving it gives me perfect load balancing (i.e., load will become 50% on pCPU 0 and 50% on pCPU 1) should I move it or not? Well, it depends if whether or not we think that the overhead we save by not migrating outweights the benefit of a perfectly balanced system. Something like that... Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-j7Io+EBtg11GKXdiSH5u 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 iQIcBAABCAAGBQJYRz48AAoJEBZCeImluHPuk50QAI1b+Dq82TK9y+un1K9QAJSM DCWHy/KhzaNV/mbJb0NlCl32A7CsNgM8wal/mMaSqi+1OKc+IZSPoEx9YQ9/fXlb vjxFsdnBw4AzPNenaxgkEi+Pmy7t5uJvd00A1TZBAO5HP/tSTwshewO7+pDpaG9p w05CfjhQ2ToX+JQjDMgd8lOOc7CRdkBno65IRRt/2a5Yy7qQ7tX4ZETAYM5tUbT6 0/ctOAcJMlhG//8fXvz7xqhOeI4SaBbjY1ZYOX3ugAPblW1c3SdzsmqJMTY48e7I uGbWWR1UyDL/YMlTi4u8DxeOAcnLBjj2iFSJMCn8kTjtb8F/vkJfhFLlrrNZenss Bou+OY7txudZpU9BNZnwm3dPFuFny+7WBr1IBCua+qLpYlCugynX20xPPOkmRGY2 mptWSXyyHZojtgkebPa7TwgizfFdc7gHFa5RHDilzHwaPSIFMrTvx36HBePmjEzz UA3U1THqeo0HhmiqIHri0HxK5Hhti9SD/gYmBdoVWUDu0Qd9p7eSgNCWxmvH8QGI mgH+1pERSCjnNIucXxmmNBsarDV+DuWnt1STqOGWkZYSVYjooWc08ow66dzovQP1 LOyWTQc+Az5NpWq21Ks7+tjk+ox6+QVbs6SoqXIJkHALHlYazukdbff52EzEyI48 KjO4qyjWNh9vk1X8mlNl =/bwF -----END PGP SIGNATURE----- --=-j7Io+EBtg11GKXdiSH5u-- --===============7025477464600051415== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7025477464600051415==--