From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] sched_rt: Improved nested virtualization performance Date: Thu, 19 Nov 2015 09:51:59 +0000 Message-ID: <1447926719.3797.21.camel@citrix.com> References: <1447903458-4736-1-git-send-email-tianyangpenn@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0752555561718498653==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZzLsr-00064g-Cu for xen-devel@lists.xenproject.org; Thu, 19 Nov 2015 09:52:05 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Meng Xu , Tianyang Chen Cc: "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org --===============0752555561718498653== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RYmcbuCjF+UZp4BFi/f9" --=-RYmcbuCjF+UZp4BFi/f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks Tianyang for the report and for the patch, and Meng for helping getting the patch itself on the list and to me, and for commenting. On Wed, 2015-11-18 at 22:38 -0500, Meng Xu wrote: > [cc. Dario...] >=20 > 2015-11-18 22:24 GMT-05:00 Tianyang Chen : > > In nested virtualization, choosing the smaller value for the > > time slice between the MAX_SCHEDULE and the budget will cause > > high host CPU usage. >=20 > Just add one comment: > I also experienced this issue when I develop Xen in a virtual box on > MacBook Air. >=20 > The root problem is not the returned time slice in rt_schedule(). The > root problem is that the CPU speed for Xen in nested virtualization > is > not constant, which breaks the budget accounting in the RTDS > scheduler, which assumes that the RTDS scheduler runs on homogenous > CPUs. >=20 I actually think the root problem _is_ the the returned timeslice in rt_schedule(), both in nested and non-nested virtualization scenarios. The reason why I want this scheduler to become event-driver, and start using timers for things like replenishments and activations as well as for budget enforcement, is to avoid having the rt_schedule() function (and all the other functions it itself calls, as of now) invoked with sub-millisecond periodicity. This makes very few sense, no matter whether the hypervisor is running on bare metal or in a VM. The proper way forward is to, _first_of_all_, fix the above, by following up on Dagaen's work. After that, we can see whether nested virt is still an issue and think to proper solutions. > I'm not sure if we should always return the MAX_SCHEDULE as the time > slice.=C2=A0=C2=A0A VCPU may have a little bit more budget (< 1ms) than i= t is > assigned on native machine if we always return MAX_SCHEDULE. >=20 With the current design, if there is a vCPU running, returning anything that is bigger than its budget, defeats any chance of enforcing such budget for that vCPU, making using this scheduler useless. So, no, I don't think we should always return MAX_SCHEDULE, I think we must fix the lack of event-driven-ess of the scheduler. > What do you think, Dario? Do you think the nested virtualization > situation is a concern right now? >=20 It probably is, but it is a consequence of how the scheduler has been designed and implemented. After all, this scheduler is still experimental for a reason, and things like this is exactly why I won't be comfortable in declaring it !experimental, until we start using timers and events properly in it. So, while we are here, Meng, can I ask whether you have a prognosis for that work? I don't like putting pressure on people, but the thing about experimental features is that it is ok for them to stay in, but some progress toward putting them out of such status should be made in every release, or we'll have to consider throwing them out. It would be therefore really good if we could get something in the 4.7 timeframe... Thanks and Regards, Dario PS. If you're receiving multiple copy of this email, sorry, it's my fault, when trying using the proper address for xen-devel! :-( --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-RYmcbuCjF+UZp4BFi/f9 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 v1 iEUEABECAAYFAlZNm78ACgkQk4XaBE3IOsTNRQCUC1LXBqRVRot1Y7nxkGlfNjXj xQCfe3Vgy/+If5xbXuzDhcJiu48ddfE= =WKx4 -----END PGP SIGNATURE----- --=-RYmcbuCjF+UZp4BFi/f9-- --===============0752555561718498653== 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 --===============0752555561718498653==--