[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] VT-d flush timeout
Jan Beulich wrote on 2014-08-22: >>>> On 22.08.14 at 09:49, <yang.z.zhang@xxxxxxxxx> wrote: >> Jan Beulich wrote on 2014-08-22: >>>>>> On 21.08.14 at 05:16, <yang.z.zhang@xxxxxxxxx> wrote: >>>> Jan Beulich wrote on 2014-08-19: >>>>>>>> "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> 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. I am not arguing. Since I am not in your meeting, so I don't know the background of the decision and I hope someone can answer my question. > > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |