[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Revisit VT-d asynchronous flush issue
>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |