On Mon, 2015-11-02 at 15:53 +0000, Wei Liu wrote: > On Mon, Nov 02, 2015 at 03:08:26PM +0000, Ian Campbell wrote: > > On Mon, 2015-11-02 at 15:00 +0000, Wei Liu wrote: > > > On Mon, Nov 02, 2015 at 12:14:50PM +0000, Ian Campbell wrote: > > > > On Mon, 2015-10-26 at 09:47 +0000, Wei Liu wrote: > > > > > The xenbus thread didn't send notification to other end when it > > > > > expected > > > > > more data or consumed responses, which led to stalling the ring > > > > > from > > > > > time to time. > > > > > > > > > > This is the culprit that guest was less responsive when using > > > > > stubdom > > > > > because the device model was stalled. > > > > > > > > > > Fix this by sending notification to the other end at the right > > > > > places. > > > > > > > > Could any of this code benefit from using the various macros in > > > > ring.h > > > > which produce or consume entries on the ring and return a _notify > > > > bit? > > > > > > > > > > The bug is it doesn't send notification at all. The existing code in > > > Linux doesn't seem to care about mitigating notifications -- xenbus > > > is > > > supposed to exchange small amount of information anyway so whether a > > > few > > > more notifications are sent is not essential. I think it would be > > > better > > > if we follow something that works at this stage. > > > > > > The use of ring macro can be considered an improvement but not > > > essential to fix the bug. It can be considered as improvement in the > > > future. > > > > My reason for suggesting it was more that we trust that those macros > > are > > already correct, compared with needing to reason from scratch about the > > open coded version used in this code which is what appeared to be going > > on. > > > > I don't think macros help here. Xenstore initialisation doesn't follow > conventional frontend and backend drivers, so the macros don't really > apply to it -- not without some refactoring.
AH, ok then. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
