Re: suspend.c vs driver-model.txt

[Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>]

>
>(Most comments were added 5 minutes ago).
>
>Does it look understendable now?

Yes, definitely more clear, there are probably interesting bits
in there to re-use for suspend-to-ram as well.
However, the mucking with kernel threads is definitely specific
to your need of keeping the target block device up without getting
nasty filesystem-originated requests.

Actually, I'm considering we could probably do both :) That is
suspend-to-disk is actually a superset of suspend-to-RAM. So
we could suspend-to-RAM-and-disk, basically allowing us to
wakeup fast from RAM, but still be able to wakeup from disk
if battery is exhausted.

Anyway, in your scheme, the main thing I'm currently concerned
about is the free_some_memory/do_suspend_sync/driver_suspend
thing which is nasty. How do you deal with memory beeing
re-allocated after free_some_memory ? (typically driver needing
RAM for saving state or a non-filesystem-related daemon doing
a kmalloc (or a driver from a tasklet). Also, do you push
as much as possible to swap ? Or may such an allocation still
cause more swap activity ? This can be nasty especially since
swap here can be an mmap'd file, or a swap file, thus possibly
racing with the fact you stopped filesystem specific daemons.

Then, finally, the drivers_suspend() state must be broken in
pieces, that is needed for both suspend-to-RAM and -to-disk,
(see my other email).

Ben.




-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31