On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
What can't we do? We've already worked with the drivers to quesce
the
hardware and put any information to resume the device in ram. Now we
ask them to put their device in low power mode so we can go to sleep.
Even if we schedule, the only thing userspace could touch is memory.
Userspace can submit I/O requests. Someone will have to audit every
driver to make sure that such I/O requests don't cause a quiesced
device to become active. If the device is active, it will make the
memory snapshot inconsistent with the on-device data.
If a driver is waking a device between the time it was told by
hibernation "suspend all operations and save your device state to ram"
and "resume your device" then it is a buggy driver.
I argue the process can make the io request after we write to disk, we
just can't service it. If we are suspended it will go to the request
queue, and eventually the process will wait for normal throttling
mechanisms until the driver is woken up.
It may mean the driver has to set a flag so that it knows it had an
iorequest arrive while it was suspended and needs to wake the queue
during its resume function.
Actually, my point was more "what kernel services do the drivers need
to transition from quiesced to low power for acpi S4 or
suspend-to-ram"? We can't give them allocate-memory (but we give them
a call "we are going to suspend" when they can), but does "run this
tasklet" help? What timer facilities are needed?
Do we need to differentate init (por by bios) and resume from quiesced
(for reboot, kexec start/resume)? I hope not.
milton
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
