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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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