Re: On setting clear criteria for declaring a feature acceptable (was "vmx: VT-d posted-interrupt core logic handling")

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

> From: George Dunlap [mailto:george.dunlap@citrix.com]
> Sent: Thursday, March 10, 2016 12:23 AM
> 
> [Changing the subject and CC'ing more people]
> 
> On 09/03/16 13:39, Jan Beulich wrote:
> >>>> On 08.03.16 at 19:38, <george.dunlap@citrix.com> wrote:
> >> If I may go "meta" for a moment here -- this is exactly what I'm talking
> >> about with "Something bad may happen" being difficult to work with.
> >> Rather than you spelling out exactly the situation which you think may
> >> happen, (which I could then either accept or refute on its merits) *I*
> >> am now spending a lot of time and effort trying to imagine what
> >> situations you may be talking about and then refuting them myself.
> [snip]
> >
> >> If you have concerns, you need to make those concerns concrete, or at
> >> least set clear criteria for how someone could go about addressing your
> >> concerns.  And yes, it is *your* job, as the person doing the objecting
> >> (and even moreso as the x86 maintainer), to make your concerns explicit
> >> and/or set those criteria, and not Feng's job (or even my job) to try to
> >> guess what it is might make you happy.
> >
> > I'm sorry, George, but no, I don't think this is how things should
> > work. If for a new feature to be enabled by default it is unclear
> > whether that puts the system at risk, it's the party suggesting the
> > default enabling to prove there's no such risk.
> 
> And it's up to the maintainers to clearly define what kind of "proof"
> would be sufficient. I have no objection to saying that Feng (or someone
> else who cares about the feature) must do some work to demonstrate that
> the feature is in fact safe before it's enabled by default; that's
> perfectly reasonable. I have already suggested something that would shed
> light on the issue and potentially satisfy me. But it's not at all
> reasonable to give them the impossible task of trying to guess what will
> satisfy you.
> 
> I don't know why this is controversial -- this seems obvious to me.
> What do other committers / maintainers think?
> 

My 2 cents here.

It's always good to have a clear definition to which extend a performance
issue would become a security risk. I saw 200us/500us used as example
in this thread, however no one can give an accrual criteria. In that case,
how do we call it a problem even when Feng collected some data? Based
on mindset from all maintainers?

I think a good way of looking at this is based on which capability is impacted.
In this specific case the directly impacted metric is the interrupt delivery
latency. However today Xen is not RT-capable. Xen doesn't commit to 
deliver a worst-case 10us interrupt latency. The whole interrupt delivery path 
(from Xen into Guest) has not been optimized yet, then there could be other 
reasons impacting latency too beside the concern on this specific list walk. 
There is no baseline worst-case data w/o PI. There is no final goal to hit. 
There is no test case to measure. 

Then why blocking this feature due to this unmeasurable concern and why
not enabling it and then improving it later when it becomes a measurable 
concern when Xen will commit a clear interrupt latency goal will be committed 
by Xen (at that time people working on that effort will have to identify all kinds 
of problems impacting interrupt latency and then can optimize together)?
People should understand possibly bad interrupt latency in extreme cases
like discussed in this thread (w/ or w/o PI), since Xen doesn't commit anything 
here.

Thanks
Kevin

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