[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
On 2013-10-18 15:43, Jan Beulich wrote: On 17.10.13 at 18:38, annie li <annie.li@xxxxxxxxxx> wrote:On 2013-10-17 17:26, Jan Beulich wrote:Yes, the issue only can be reproduced in 32-bit Dom0 (Beyond MAX_ULONG/2 in 64-bit will need long long time) I think the gap should be think all environment even now extending 480+. if now fall in the gap, one timer will be pending and replenish will be in time. Please run the attachment test program.Not sure what this is supposed to tell me. I recognize that there are overflow conditions not handled properly, but (a) I have a hard time thinking of a sensible guest that sits idle for over 240 days (host uptime usually isn't even coming close to that due to maintenance requirements) and (b) if there is such a sensible guest, then I can't see why dealing with one being idle for over 480 days should be required too.If the guest contains multiple NICs, that situation probably happens when one NIC keeps idle and others work under load. BTW, how do you get the 240?2^31 / 100 / 60 / 60 / 24 Obviously with HZ=1000 the span would be smaller by a factor of 10, which would make it even more clear that doubling the span doesn't really help. My understanding is this patch does not simply double the span, it is just stricter than the original one. Please check my previous comments, I paste it here. The main change of this patch is copied here too, if (!time_in_range_open(now, vif->credit_timeout.expires, next_credit)) comments:----------expires-------now-------credit---------- is the only case where we need to add a timer. Other cases like following would match the if condition above, then no timer is added. ----------expires----------credit------now------ -----now-----expires----------credit----------Or we can consider the extreme condition, when the rate control does not exist, "credit_usec" is zero, and "next_credit" is equal to "expires". The above if condition would cover all conditions, and no rate control really happens. If credit_usec is not zero, the "if condition" would cover the range outside of that from expires to next_credit. Even if "now" is wrapped again into the range from "expires" to "next_credit", the "next_credit" that is set in __mod_timer is reasonable value(this can be gotten from credit_usec), and the timer would be hit soon. Thanks Annie _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |