[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH][RESEND] Fix stale-state issue with 'xm dom{id, name}'

Dan Smith wrote:

EM> I've been trying to decide how easy it would be to fix the
EM> underlying problem -- if it's going to take a long time, then I'll
EM> apply your patch as a workaround, but I hope to solve the problem
EM> more definitively.

I think the solution (or best fix) is to standardize on the fact that
we always update domain information right before we return it, and
purge that information if needed.  I think that "xm list" triggers
this somewhere deep inside xend, as I can always purge the stale data
by running an "xm list".  This tells me that some async signals aren't
always being sent to clean up, which means "xm list" has to trigger
it.  I *think* Anthony had a comment about polling being necessary in
this case for some reason, so perhaps he can chime in and explain.
Actually, Keir made a recent change that will cause the @releaseDomain notification to go out when the domain disappears which was the thing that necessitated polling before.

As long as Xend updates it's state on every @introduceDomain and @releaseDomain watch, it should always be up-to-date (barring the obvious scheduling race between Xend and XenStore--but that only allows a stale domain state window of a few 10s of milliseconds at worse).

What would be really ideal is to do away completely with the Xend internal state and just always pull things from the store. This is probably too big of a change for 3.0 though.


Anthony Liguori

Thanks Ewan!

Xen-devel mailing list



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