[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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.