| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH][RESEND] Fix stale-state issue with 'xm dom{id, n
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.
Regards,
Anthony Liguori
Thanks Ewan!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home