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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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