From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: VT-d flush timeout Date: Fri, 22 Aug 2014 08:58:24 +0100 Message-ID: <53F71440020000780002C8C9@mail.emea.novell.com> References: <53F2042E02000078000BAAD6@mail.emea.novell.com> <53F358F702000078000BAC69@mail.emea.novell.com> <53F70E86020000780002C889@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Yang Z Zhang Cc: LiangX Z Li , "andrew.cooper3@citrix.com" , Kevin Tian , Donald D Dugger , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 22.08.14 at 09:49, wrote: > Jan Beulich wrote on 2014-08-22: >>>>> On 21.08.14 at 05:16, wrote: >>> Jan Beulich wrote on 2014-08-19: >>>>>>> "Zhang, Yang Z" 08/19/14 3:34 AM >>> >>>>> My only concern is that, for QI flush, the spin time relies on the >>>>> length of the queue. I am not sure whether 1s is enough for worst >>>>> case and I think we should remove the 1s in QI flush. And I think >>>>> this also the same reason for Linux don't use timeout mechanism in >>>>> QI >> flush. >>>> >>>> First of all I think both Linux and Xen in the majority of cases >>>> waits for completion of just individual queue entries. I.e. I'm not >>>> sure if the practical worst case really is equal to the theoretical >>>> one. And >>> >>> This is my guessing from Linux's implementation but may wrong. >> >> Which is why we ask for you (the VT-d maintainer) to, as a first step, >> supply a patch limiting the spinning time to a value smaller than the >> current on, just enough to cover real requirements. The second step > > This doesn't answer my question. I still don't see why a smaller value > helps. Because it reduces the impact the currently large value would have in misbehaving cases? Don clearly indicated to me that it shouldn't be a big deal to reduce the current timeout, so I really don't see what all this argument is about. Jan