On Mon, 2005-08-29 at 01:27 +0100, Christian Limpach wrote:
> On Mon, Aug 29, 2005 at 10:12:01AM +1000, Rusty Russell wrote:
> > On Fri, 2005-08-26 at 11:28 +0100, Christian Limpach wrote:
> > This is why suspend takes the xenbus_lock; it just doesn't make sense
> > otherwise (even without transactions, you could have issued half a
> > command, then get migrated to another machine and another store, and
> > you'd be screwed).
>
> I didn't mean checkpointing suspend, but the guest getting descheduled
> for an arbitrary amount of time, in the worst case the guest getting
> user paused for a very long time. Bad luck if it's during a transaction
> and the store times out the transaction, what then?
Any contested resource has this issue; we resolve it by breaking the
lower-priority one if they take too long in the case of conflict, rather
than hanging forever.
If this actually starts happening, we might need to revisit, but I think
it's a symptom of a larger problem of starvation. Currently
transactions from domains are always on local areas, so it can only
conflict with removing the device nodes, which is fine...
Thanks!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home