On Tuesday, 27 of November 2007, Kyle Moffett wrote:
quoted text
> On Nov 27, 2007, at 12:40:24, Rafael J. Wysocki wrote:
> > On Tuesday, 27 of November 2007, Matthew Garrett wrote:
> >> On Mon, Nov 26, 2007 at 10:53:34PM +0100, Rafael J. Wysocki wrote:
> >>> On Monday, 26 of November 2007, David Chinner wrote:
> >>>> So how do you handle threads that are blocked on I/O or a lock  
> >>>> during the system freeze process, then?
> >>>
> >>> We wait until they can continue.
> >>
> >> So if I have a process blocked on an unavilable NFS mount, I can't
> >> suspend?
> >
> > That's correct, you can't.
> >
> > [And I know what you're going to say. ;-)]
> 
> Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE"  
> instead of a zero preempt_count()?  Really what we should do is just  
> iterate over all of the actual physical devices and tell each one  
> "Block new IO requests preemptably, finish pending DMA, put the  
> hardware in low-power mode, and prepare for suspend/hibernate".  As  
> long as each driver knows how to do those simple things we can have  
> an entirely consistent kernel image for both suspend and for  
> hibernation.

Well, this is more-or-less how we all imagine that should be done eventually.

The main problem is how to implement it without causing too much breakage.
Also, there are some dirty details that need to be taken into consideration.

quoted text
> When all tasks are preemptable we can very trivially rely on the  
> drivers to enforce the "Stop new IO submission" with a dirt-simple  
> semaphore or waitqueue.  The sleep itself will be  
> TASK_UNINTERRUPTIBLE, but it will be done from a preemptible context.

If there are any drivers that make their devices available via mmap(), that
won't be sufficient.

Probably, we'll need a two iterations over devices to handle all corner cases.

Moreover, for hibernation we need to resume at least some devices in order
to save the image, which shouldn't result in unblocking the waiting tasks.

quoted text
> That way the system suspend time is the sum of the suspend times of  
> the devices on the system, and the suspend time of any given device  
> is the sum of its maximum non-preemptible critical section and the  
> time to flush all of its remaining pending DMA/etc.  This is almost  
> completely independent of the load-level of the machine, and it does  
> not depend on things like NFS filesystems.  The one gotcha is that it  
> does not flush dirty filesystem pages to disk first, although that  
> could be fixed with a few VFS and blockdev hooks which hierarchically  
> flush and "freeze" block devices and filesystems before actually  
> disabling devices much the way that device-mapper can pause a device  
> to take a snapshot and end up with a clean journal on the filesystem  
> afterwards.

Yes, I generally agree.

Greetings,
Rafael
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/