[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))


----------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.

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.