[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] /proc/xen/xenbus supports watch?
On Thu, 2005-09-22 at 18:01 -0700, Andrew Warfield wrote: > Rusty, > > Can you explain once again why you think that migrating in-progress > transactions is the right thing to do? It seems to me that our > transactions are generally pretty small, and I don't imagine them > getting problematically bigger in the future. If client-side > transaction code is already being written to expect failures and retry > when they occur, what is the argument against blowing away in-progress > transactions when you migrate. > > Given that the majority of current transaction code is to do with > device drivers and you disconnect/reconnect those on migration anyway, > why go through the extra work of adding complexity to migration? Actually, with more thought on your excellent points I've changed my mind: we should wait for any transactions to complete before saving domain and sidestep the whole issue. To recap, the problem is that if we are are halfway through a transaction when we migrate the domain, it's hard to know what to do on the next op (eg. "xs_write", "xs_read" etc). Without migrating the transaction, we can fail the next op with EAGAIN or return "dummy" values, neither of which is pleasant. (Failing with EAGAIN on commit is different, and something the caller needs to handle anyway). Now, we already have this "domain won't save until transactions are done" simply because we use a single big lock, but this discussion started because we want to get rid of that lock for /proc/xen/xenbus (it's fine for drivers). I think we should do so, but keep this wont-save-during-transactions semantic; it means a waitqueue etc, but I don't think it's too bad. As you say, our transactions are pretty small. Do people like this more? Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |