Re: [Xen-devel] DomU's network interface will hung when Dom0 running 32bit

[jianhai luan <jianhai.luan@xxxxxxxxxx>]

On 2013-10-16 21:47, Wei Liu wrote:
> On Wed, Oct 16, 2013 at 09:08:03PM +0800, jianhai luan wrote:
> [...]
> > > > >     expires   now   next_credit
> > > > >     ----time increases this direction--->
> > > > >
> > > > > * time_after_eq(now, next_credit) -> false
> > > > > * time_before(now, expires) -> false
> > > > >
> > > > > Then it's stuck again. You're merely narrowing the window, not fixing
> > > > > the real problem.
> > > > The above environment isn't stack again. The netback will
> > > > pending one timer to process the environment.
> > > >
> > > > The attachment program will prove if !(time_after_eq(now,
> > > > next_credit) || time_before(now, vif->credit_timeout.expires)),
> > > > now will only be placed in above environment [ expires
> > > > next_credit),  and the above environment will be processed by
> > > > timer in soon.
> > > Or check following to see what the if condition really do,
> > >
> > > ----------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's express, my option is consistent with Annie.
> OK, thanks for the explanation. I think I get the idea.
>
> In any case, could you use !time_in_range / !time_in_range_open instead
> of open coded one-liner? Though I presume one-liner open coding would
> not hurt.
I agree above the suggest. The attachment patch may be better than 
previous patch.
Jason
> Wei.

Attachment: 0001-xen-netback-pending-timer-only-in-the-range-expire-n.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel