From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [RFC 0/5] xen/arm: support big.little SoC Date: Mon, 19 Sep 2016 14:03:32 -0700 (PDT) Message-ID: References: <1474250936-27962-1-git-send-email-peng.fan@nxp.com> <10152e13-bccb-0794-44e4-556845875e33@arm.com> <20160919083619.GA16854@linux-7smt.suse> <5ddefbc1-3bd4-c990-b615-0039761535d8@arm.com> <97d77bdb-2f4e-e89a-95b9-8aacb56eebc0@suse.com> <1474305482.4393.42.camel@citrix.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1555934771-1474319013=:26423" Return-path: In-Reply-To: <1474305482.4393.42.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Dario Faggioli Cc: Juergen Gross , Peng Fan , Stefano Stabellini , George Dunlap , Andrew Cooper , "xen-devel@lists.xen.org" , Julien Grall , Jan Beulich , Peng Fan List-Id: xen-devel@lists.xenproject.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1555934771-1474319013=:26423 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 19 Sep 2016, Dario Faggioli wrote: > On Mon, 2016-09-19 at 12:23 +0200, Juergen Gross wrote: > > On 19/09/16 12:06, Julien Grall wrote: > > > On 19/09/2016 11:45, George Dunlap wrote: > > > > But expanding the schedulers to know about different classes of > > > > cpus, > > > > and having vcpus specified as running only on specific types of > > > > pcpus, > > > > seems like a more flexible approach. > > > > > > So, if I understand correctly, you would not recommend to extend > > > the > > > number of CPU pool per domain, correct? > > > > Before deciding in which direction to go (multiple cpupools, sub- > > pools, > > kind of implicit cpu pinning) > > > You mention "implicit pinning" here, and I'd like to stress this, > because basically no one (else) in the conversation seem to have > considered it. In fact, it may not necessarily be the best long term > solution, but doing something based on pinning is, IMO, a very > convenient first step (and may well become one of the 'modes' available > to the user for taking advantage of big.LITTLE. > > So, if cpus 0-3 are big and cpus 4,5 are LITTLE, we can: >  - for domain X, which wants to run only on big cores, pin all it's >    vcpus to pcpus 0-3 >  - for domain Y, which wants to run only on LITTLE cores, pin all it's >    vcpus to pcpus 4,5 >  - for domain Z, which wants its vcpus 0,1 to run on big cores, and >    it's vcpus 2,3 to run on LITTLE cores, pin vcpus 0,1 to pcpus 0-3,  >    and pin vcpus 2,3 to pcpus 4,5 > > Setting thing up like this, even automatically, either in hypervisor or > toolstack, is basically already possible (with all the good and bad > aspects of pinning, of course). > > Then, sure (as I said when replying to George), we may want things to > be more flexible, and we also probably want to be on the safe side --if > ever some components manages to undo our automatic pinning-- wrt the > scheduler not picking up work for the wrong architecture... But still > I'm a bit surprised this did not came up... Julien, Peng, is that > because you think this is not doable for any reason I'm missing? Let's suppose that Xen detects big.LITTLE and pins dom0 vcpus to big automatically. How can the user know that she really needs to be careful in the way she pins the vcpus of new VMs? Xen would also need to pin automatically vcpus of new VMs to either big or LITTLE cores, or xl would have to do it. The whole process would be more explicit and obvious if we used cpupools. It would be easier for users to know what it is going on -- they just need to issue an `xl cpupool-list' command and they would see two clearly named pools (something like big-pool and LITTLE-pool). We wouldn't have to pin vcpus to cpus automatically in Xen or xl, which doesn't sound like fun. --8323329-1555934771-1474319013=:26423 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --8323329-1555934771-1474319013=:26423--