[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] DomU's network interface will hung when Dom0 running 32bit
On 2013-10-16 0:03, Wei Liu wrote: On Tue, Oct 15, 2013 at 11:19:42PM +0800, jianhai luan wrote: [...]* time_after_eq(now, next_credit) -> false * time_before(now, expires) -> falseIf now is placed in above environment, the result will be correct (Sending package will be not allowed until next_credit).No, it is not necessarily correct. Keep in mind that "now" wraps around, which is the issue you try to fix. You still have a window to stall your frontend.Remember that time_after_eq is supposed to work even with wraparound occurring, so long as the two times are less than MAX_LONG/2 apart.Sorry for my misunderstand explanation. I mean that * time_after_eq()/time_before_eq() fix the jiffies wraparound, so please think about jiffies in line increasing. * time_after_eq()/time_before_eq() have the range (0, MAX_LONG/2), the judge will be wrong if out of the range. So please think about three kind environment - expires now next_credit --------time increases this direction ----------> - expires [next_credit now next_credit+MAX_LONG/2 --------time increase this direction -----------> - expires next_credit next_credit+MAX_LONG/2 now --------time increadse this direction ----------> The first environment should be netfront consume all credit_byte before next_credit, So we should pending one timer to calculator the new credit_byte, and don't transmit until next_credit. the second environment should be calculator the credit_byte because netfront don't consume all credit_byte before next_credit, and time_after_eq() do correct judge. the third environment should be calculator in time because netfront don't consume all credit_byte until next_credit.But time_after_eq do error judge (time_after_eq(now, next_credit) is false), so the remaining_byte isn't be increased. and I work on the third environment. You know now > next_credit+MAX_LONG/2, time_before(now, expire) should be true(time_before(now, expire) is false in first environment)Thanks for staighten this out for me. I'm just too dumb for this, please be patient with me. :-) Could you prove that time_before(now, expire) is always true in third case? That's where my main cencern lies. Is it because msecs_to_jiffies always returns MAX_JIFFY_OFFSET (which is ((LONG_MAX >> 1)-1) ) at most? I have wrong judge in third environment. If now large than expires + MAX_UNLONG, time_before(now, expires) will be false. expires next_credit next_credit+MAX_UNLONG/2 expires + MAX_UNLONG now next_credit+MAX_UNLONG --------------------------------------------------------- time increadse this direction ----------------------------------> In the above environment, time_before(now, expires) will return false. But the jiffies elapsed more time and next_credit will be reachable in soon(time_after_eq(now, next_credit) will be true). Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |