From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Revisit VT-d asynchronous flush issue Date: Tue, 3 Nov 2015 09:58:58 +0000 Message-ID: <56388562.70605@citrix.com> References: <56377CC802000078000B0C6F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56377CC802000078000B0C6F@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Kevin Tian Cc: Jun Nakajima , "keir@xen.org" , "ian.campbell@citrix.com" , "george.dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "tim@xen.org" , "xen-devel@lists.xen.org" , Yang Z Zhang , Quan Xu , Rajesh Sankaran List-Id: xen-devel@lists.xenproject.org On 02/11/15 14:10, Jan Beulich wrote: >>>> On 02.11.15 at 09:03, 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