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