has
requested the image to be not greater than 50% of RAM. In that case you
have
to free some memory _before_ identifying memory to save and you must not
race with applications that attempt to allocate memory while you're doing
it.
I disagree a little bit.
first off, only the suspending kernel can know what can be freed and what
is needed to do so (remember this is kernel internals, it can change from
patch to patch, let alone version to version)
second, if you have a lot of memory to free, and you can't just throw away
caches to do so, you don't know what is going to be involved in freeing
the memory, it's very possilbe that it is going to involve userspace, so
you can't freeze any significant portion of the system, so you can't
eliminate all chance of races
what you can do is
1. try to free stuff
2. stop the system and account for memory, is enough free
if not goto 1
if userspace is dirtying memory fast enough, or is just useing enough
memory that you can't meet your limit you just won't be able to suspend.
but under any other conditions you will eventually get enough memory free.
so try several times and if you still fail tell the user they have too
much stuff running and they need to kill something.
Which would be a pretty big regression from what we have now. With the
current implementation I can hibernate under virtually any workload because
the freezer stops everything and there's no competition for resources.