Re: [Xen-devel] Revisit VT-d asynchronous flush issue

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, November 03, 2015 6:04 PM
> 
> >>> On 03.11.15 at 10:58, <george.dunlap@xxxxxxxxxx> wrote:
> > On 02/11/15 14:10, Jan Beulich wrote:
> >>>>> On 02.11.15 at 09:03, <kevin.tian@xxxxxxxxx> wrote:
> >>> Based on above information, we propose to continue spin-timeout
> >>> model w/ some adjustment, which fixes current timeout concern
> >>> and also allows limited ATS support in a light way:
> >>>
> >>> 1) reduce spin timeout to 1ms, which can be boot-time changed
> >>> up to 10ms.
> >
> > Out of curiosity, is there a reason to limit the timeout to 10ms?
> >
> > I'm generally a believer that we should do something sensible by
> > default, but that an admin -- particularly someone who is going to be
> > messing around with this sort of setting -- should be allowed to "shoot
> > themselves in the foot" if they want to.
> >
> > Suppose that there's some particularly grotty piece of hardware that
> > really does require a 30ms, or 100ms timeout to work effectively?  If we
> > have a hard limit of 10ms, there's nothing the person can do other than
> > re-compile Xen.  If we have no hard limit, they can simply set it to
> > 100ms as a work-around until we get asynchronous flushing working.
> 
> Andrew requested that too, and I understood that's what's planned
> to be implemented.
> 

Yes, that's the deal. :-)

Thanks
Kevin

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