Re: [Xen-devel] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2016-03-10 at 11:00 +0000, George Dunlap wrote:
> > > > > On 10.03.16 at 11:05, <kevin.tian@xxxxxxxxx> wrote:
> > > >  From: Tian, Kevin
> > > > Sent: Thursday, March 10, 2016 5:20 PM
> > > > 
> > > 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.
> > > 
> > > 
> Re "an IPI is sent to PCPU1", all that should be transparent to the
> PI
> code -- it already calls vcpu_unblock(), which will call vcpu_wake(),
> which calls the scheduling wake code, which will DTRT.
> 
Exactly. In fact, whether there will be any IPI involved is under
control of the scheduler, rather than of PI code, even right now.

In fact, no matter in what pCPU's blocked list a vCPU is, it is the
'tickling' logic (for all Credit, Credit2 and RTDS) that really decides
on which pCPU the vCPU should wakeup, and send the IPI, if that is not
the pCPU we're running on.

It can be argued that having a vCPU in the blocked list of the pCPU
where it was running when it blocked could be a good thing, because it
may then be able to restart running there when waking, which may have
positive cache effects, etc.
But that is not at all guaranteed. In fact, it could well be the case
in fairly idle systems, but under high load and/or if hard and soft
affinity are in use (which may well be the case, .e.g, on large NUMA
servers), that isn't necessarily true, and we should not base on such
assumption.

> FWIW I have much less objection to this sort of solution if it were
> confined to the PI arch_block() callback, rather than something that
> required changes to the schedulers.
> 
Same here, and I think this can well be done in such a way... Worth a
shot, IMO.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel