|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|