Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, July 08, 2015 8:46 PM
> 
> >>> On 08.07.15 at 13:00, <kevin.tian@xxxxxxxxx> wrote:
> >> @@ -1848,6 +1869,33 @@ static struct hvm_function_table __initdata
> >> vmx_function_table = {
> >>      .enable_msr_exit_interception = vmx_enable_msr_exit_interception,
> >>  };
> >>
> >> +/*
> >> + * Handle VT-d posted-interrupt when VCPU is blocked.
> >> + */
> >> +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
> >> +{
> >> +    struct arch_vmx_struct *vmx;
> >> +    unsigned int cpu = smp_processor_id();
> >> +
> >> +    spin_lock(&per_cpu(pi_blocked_vcpu_lock, cpu));
> >> +
> >> +    /*
> >> +     * FIXME: The length of the list depends on how many
> >> +     * vCPU is current blocked on this specific pCPU.
> >> +     * This may hurt the interrupt latency if the list
> >> +     * grows to too many entries.
> >> +     */
> >
> > let's go with this linked list first until a real issue is identified.
> 
> This is exactly the way of thinking I dislike when it comes to code
> that isn't intended to be experimental only: We shouldn't wait
> for problems to surface when we already can see them. I.e. if
> there are no plans to deal with this, I'd ask for the feature to be
> off by default and be properly marked experimental in the
> command line option documentation (so people know to stay
> away from it).
> 

I don't see big problem here. For typical server consolidation ratio
1:4 or 1:8, the link list should be short. It's not experimental. It's
based on our judge that linked list should be fine here. But any
structure may has potential problem which we don't know now,
just like tasklet scalability issue Andrew raised earlier (in that case
we can't blame anyone using tasklet before the issue is reported).

So, there's no plan to address this since we don't see real problem
now. I'd suggest Feng to remove the comment since FIXME means
something experimental. Or if you have a better suggestion, please
articulate instead of asking people stay away from it.

Thanks
Kevin



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