[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] vmx: VT-d posted-interrupt core logic handling
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] > Sent: Tuesday, May 17, 2016 9:27 PM > To: Wu, Feng <feng.wu@xxxxxxxxx> > Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; Jan Beulich <JBeulich@xxxxxxxx>; > Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Dario Faggioli > <dario.faggioli@xxxxxxxxxx>; David Vrabel <david.vrabel@xxxxxxxxxx>; > GeorgeDunlap <george.dunlap@xxxxxxxxxx>; Lars Kurth <lars.kurth@xxxxxxxxxx>; > George Dunlap <George.Dunlap@xxxxxxxxxxxxx>; Ian Jackson > <Ian.Jackson@xxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx > Subject: Re: vmx: VT-d posted-interrupt core logic handling > > On Thu, Mar 10, 2016 at 01:36:34PM +0000, Wu, Feng wrote: > > > > > > > -----Original Message----- > > > From: Tian, Kevin > > > Sent: Thursday, March 10, 2016 6:06 PM > > > To: Jan Beulich <JBeulich@xxxxxxxx> > > > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Dario Faggioli > > > <dario.faggioli@xxxxxxxxxx>; David Vrabel <david.vrabel@xxxxxxxxxx>; > > > GeorgeDunlap <george.dunlap@xxxxxxxxxx>; Lars Kurth > <lars.kurth@xxxxxxxxxx>; > > > George Dunlap <George.Dunlap@xxxxxxxxxxxxx>; Ian Jackson > > > <Ian.Jackson@xxxxxxxxxxxxx>; Wu, Feng <feng.wu@xxxxxxxxx>; xen- > > > devel@xxxxxxxxxxxxx; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > > > Subject: RE: vmx: VT-d posted-interrupt core logic handling > > > > > > > > > Hi, Jan, > > > > > > I'm thinking your earlier idea about evenly distributed list: > > > > > > -- > > > Ah, right, I think that limitation was named before, yet I've > > > forgotten about it again. But that only slightly alters the > > > suggestion: To distribute vCPU-s evenly would then require to > > > change their placement on the pCPU in the course of entering > > > blocked state. > > > -- > > > > > > Actually after more thinking, there is no hard requirement that > > > the vcpu must block on the pcpu which is configured in 'NDST' > > > of that vcpu's PI descriptor. What really matters, is that the > > > vcpu is added to the linked list of the very pcpu, then when PI > > > notification comes we can always find out the vcpu struct from > > > that pcpu's linked list. Of course one drawback of such placement > > > is additional IPI incurred in wake up path. > > > > > > Then one possible optimized policy within vmx_vcpu_block could > > > be: > > > > > > (Say PCPU1 which VCPU1 is currently blocked on) > > > - As long as the #vcpus in the linked list on PCPU1 is below a > > > threshold (say 16), add VCPU1 to the list. NDST set to PCPU1; > > > Upon PI notification on PCPU1, local linked list is searched to > > > find VCPU1 and then VCPU1 will be unblocked on PCPU1; > > > > > > - Otherwise, add VCPU1 to PCPU2 based on a simple distribution > > > algorithm (based on vcpu_id/vm_id). VCPU1 still blocks on PCPU1 > > > but NDST set to PCPU2. Upon notification on PCPU2, local linked > > > list is searched to find VCPU1 and then an IPI is sent to PCPU1 to > > > unblock VCPU1; > > > > > > Feng, do you see any overlook here? :-) > > > > Kevin, thanks for the suggestion, it sounds a good idea, I will think > > it a bit more and do some trials based on it. > > Hey! > > I am curious how the trials went? This feature is pretty awesome and > I am wondering what the next step is? Good to know that you are interested in this feature. However, I have been occupied by another things recently, I think I will continue this work some time later. Thanks, Feng > > Thanks! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |