[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ehancement to domU suspend/resume
On 18/1/07 7:27 am, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > Freeze basically puts all other processes into a frozen point with no > lock held. For kernel thread, each one is required to check freezing > flag (by try_to_freeze) at each loop out of critical chunk, and then yield > or sleep if set. For user space process, a dummy signal notification is > sent to that process which will then check freezing flag when do_signal > before returning to user space. This can assure all processes falling > into a save point before drivers are ready to suspend. Thaw just does > the reverse to unfreeze them when resume. > > Yes, it may have to wait some time for all processes to be frozen, and I > have no estimation. But it's a necessary step to put whole box into a > stable state. Is there any flag to check whether current domU is a driver > domain? Then we can differentiate two paths. Well, let's see what latency it adds in practise. I believe the kernel guys are going to use the process refrigerator for CPU hotplug so we may have to go this route anyway long term. One fear I have is that user processes doing xenbus transactions may be unable to enter the fridge if they are waiting for the transaction mutex (which is locked out across save/restore xenbus_suspend()/xenbus_resume()). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |