Hi!
> >> Ok! I see the advantages / disadvantages of each version. But what
> >> happens if the memory AND swap space are full and nothing can't be
> >> freed? When I watch the memory and swap consumption on my laptop, I
> >> think it's the most time the case...
> >
> > If you're getting yourself in that situation, you should be increasing
> > your swap space (and memory if possible) anyway.
> >
> >> Another question:
> >> Is it a big problem to save the memory in a separate file on the file
> >> system, and save somewhere the pointer to it (as example in swap. Also
> >> we could set a flag in swap so that we now that the last shutdown was
> >> a hybernation). One Problem will be, that we don't know the filesystem
> >> type on resume...(We could save the module in swap...)
> >> All that is just theoretical. It's only a idea.
> >
> > I guess the simplest answer is would it be worth the pain? Since disk
> > space is cheap, it just requires a little forethought when installing
> > Linux, to ensure enough swap is allocated. I certainly understand that
> > using a file rather than swap makes adjusting the amount of space
> > available easier, but as you rightly acknowledge, it does complicate
> > things a fair bit more.
>
> Can't you just create a pre-reserved separate swsusp area on disk the size
> of RAM (maybe a partition rather than a file to make things easier), and
> then you know you're safe (basically what Marc was suggesting, except pre-allocated)? Or does that make me the prince of all evil? ;-)
>
> However much swap space you allocate, it can always all be used, so that
> seems futile ...
Well, but if all the swaps gets used, you go OOM and randomly kill
processes. That means that machines have way more swap than they need.
If you really want to "solve" it reliably, you can always
swapon /dev/hdfoo666
where hdfoo666 is as big as ram, just before starting swsusp. We could
even make swapon part of swsusp where its locked to kill races.
But I believe its not needed. Problem just is not there in practise.
Pavel
-- Horseback riding is like software... ...vgf orggre jura vgf serr. - 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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:39 EST