From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wu, Feng" Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Tue, 14 Jul 2015 05:44:31 +0000 Message-ID: References: <1435123109-10481-15-git-send-email-feng.wu@intel.com> <55918214.4030102@citrix.com> <1435633087.25170.274.camel@citrix.com> <1435825253.25170.406.camel@citrix.com> <559E6EB7.3050609@eu.citrix.com> <559E96E0020000780008ED84@mail.emea.novell.com> <1436451512.22672.333.camel@citrix.com> <559E84EF.7060507@eu.citrix.com> <559F80C6020000780008F348@mail.emea.novell.com> <1436526348.22672.387.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436526348.22672.387.camel@citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Jan Beulich , George Dunlap Cc: "Tian, Kevin" , "keir@xen.org" , "andrew.cooper3@citrix.com" , xen-devel , "Zhang, Yang Z" , "Wu, Feng" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > Sent: Friday, July 10, 2015 7:06 PM > To: Jan Beulich > Cc: Wu, Feng; andrew.cooper3@citrix.com; George Dunlap; Tian, Kevin; Zhang, > Yang Z; xen-devel; keir@xen.org > Subject: Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor > during vCPU scheduling > > On Fri, 2015-07-10 at 07:22 +0100, Jan Beulich wrote: > > >>> On 10.07.15 at 07:59, wrote: > > > If you agree with doing all this in a central place, maybe we can create > > > an arch hook for 'struct scheduler' to do this and call it in all the places > > > vcpu_runstate_change() gets called. What is your opinion about this? > > > > Doing this in a central place is certainly the right approach, but > > adding an arch hook that needs to be called everywhere > > vcpu_runstate_change() wouldn't serve that purpose. > > > Indeed. > > > Instead > > we'd need to replace all current vcpu_runstate_change() calls > > with calls to a new function calling both this and the to be added > > arch hook. > > > Well, I also see the value of having this done in one place, but not to > the point of adding something like this. > > > But please wait for George's / Dario's feedback, because they > > seem to be even less convinced than me about your model of > > tying the updates to runstate changes. > > > Indeed. George stated very well the reason why vcpu_runstate_change() > should not be used, and suggested arch hooks to be added in the relevant > places. I particularly like this idea as, not only it would leave > vcpu_runstate_change() alone, but it would also help disentangling this > from runstates, which, IMO, is also important. > > So, can we identify the state (runstate? :-/) transitions that needs > intercepting, and find a suitable place where to place hooks? I mean, > something like this: > > - running-->blocked: can be handled in the arch specific part of > context switch (similarly to CMT/CAT, which > already hooks into there). So, in this case, no > need to add any hook, as arch specific code is > called already; > > - running-->runnable: same as above; > > - running-->offline: not sure if you need to take action on this. If > yes, context switch should be fine as well; > > - blocked-->runnable: I think we need this, don't we? If yes, we > probably want an arch hook in vcpu_wake(); > > - blocked-->offline: do you need it? Well, the hook in wake should work > for this as well, if yes; > > - runnable/running-->offline: if necessary, we want an hook in > vcpu_sleep_nosync(). > > Another way to look at this, less biased toward runstates (i.e., what > I've been asking for since a while), would be: > > - do you need to perform an action upon context switch (on prev and/or > next vcpu)? If yes, there's an arch specific path in there already; > - do you need to perform an action when a vcpu wakes-up? If yes, we > need an arch hook in vcpu_wake(); > - do you need to perform an action when a vcpu goes to sleep? If yes, > we need an arch hook in vcpu_sleep_nosync(); > > I think this makes a more than fair solution. I happen to like it even > better than the centralized approach, actually! That is for personal > taste, but also because I think it may be useful for others too, in > future, to be able to execute arch specific code, e.g., upon wakes-up, > in which case we will be able to use the hook that we're introducing > here for PI. > Hi George, any ideas about this? Thanks, Feng > Thanks and Regards, > Dario > > -- > <> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)