RE: [linux-pm] Re: Hibernation considerations

Alan Stern
2007-07-24T14:50:54Z

On Tue, 24 Jul 2007, Huang, Ying wrote:

> >From: Alan Stern [mailto:stern@rowland.harvard.edu]
> >It can't. Indeed, in the absence of a freezer, user threads will need
> >devices (more accurately, will submit I/O requests for devices) that
> >have to be kept quiescent or low-power. Drivers will need to delay
> >those requests until the devices are returned to full operation.
> >
> >That's exactly what I've been saying all along: Drivers will need to
> >be changed to delay I/O requests, if there is no freezer.
>
> If it is a too big work to implement "delaying I/O requests" for every
> driver, is it possible to implement it as follow:
>
> 1. It is triggered to suspend to RAM/DISK.
> 2. Replace the driver related syscall entries (such as sys_read,
> sys_write, sys_ioctl, etc) in sys_call_table with special wrapper
> entries provided by "suspend to RAM/DISK" subsystem, which will delay
> I/O requests if appropriate.
> 3. When devices are quiesced, they are put into "low power" state and
> system is put into suspend state; or the image is written to disk
> (through snapshot/uswsusp or kexeced kernel).
> 4. After resuming from RAM/DISK, devices are put into "normal" state and
> the syscall entries replaced in step 2 are restored.

Ha! I made exactly this same suggestion (URL lost in the mists of
time), except that I proposed changing the syscall entries for every
system call, not just the driver-related ones.

Nobody seemed to think it would work very well.

It leaves a few loose ends. For example, suppose a user thread is
already in the middle of a system call and is about to start doing some
I/O (maybe it's waiting for a timer to expire).

In the end, this doesn't seem to be very different from freezing all
user threads.

Alan Stern