> Making snapshots will not be available in this kind of implementation,
> because suspending hangs on swap state [every process is tried to swapped
> out, so image won't be that big], and the state of filesystems also.
> This is a drawback [so I can't suspend a state, run another [not using
> that swap!] then continue the first one]. This is not good, because nfs
> filesystem may vary meantime [and why wouldn't they do that?].
Don't worry. NFS may vary _anytime_ so if you'll break it with your
patch, it was broken anyway. (Your linux machine may hung for 1hour
doing cli(); for(i=0; i<some_very_big_number; i++); sti(); without too
much things breaking. Do now worry.)
> Every possible info is shrinked [inode, buffer, dcache] but I don't know
> what to do with those are in use..
> Maybe we should revalidate them? But what if we did this suspend in the
> meantime of writing a buffer [and haven't marked it dirty yet - we
> load a previous state..].
> And what if we marked it... to reavalidate we have to flush it to disk as
> it is [with unfinished modifying]... It is not a problem if we continue
> with the original state but running another one [or a new one] is
> definitely bad.. FS corruption ... :O
You should probably expect the original state (try to solve easy task
first).
> 2) On shrinking memory [to swap] I did call try_to_free_pages with gfp
> mask __GFP_WAIT. And it slept [of course :)]. So other processes were
> still running :(. [my mpeg player e.g.]. How to disable them? [It made an
...
> I was thinking of a shortcut in schedule() [if suspeinding is in progress
> then don't run any other process than the suspending one] But it's
> _ugly_.
You could create process with big rt priority and make it do while(1);
This should guarantee that no other process will have chance to
run. Of course your "suspender" process will have to have even higher
priority ;-).
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/