Re: [Bug #13058] First hibernation attempt fails

Pavel Machek
2009-04-07T08:06:32Z

Hi!

> And the thing is, swsusp_save() really does do odd things. For example, to
> get rid of unnecessary memory, it does "drain_local_pages()", where the
> "local" is "local cpu". Why does it do that? Likely nobody knows.

I do :-). atomic image copying needs to copy any and all used pages,
and needs to know beforehand how many to copy. local pages are
strange in this area, so we just get rid of them to simplify stuff.

> For example, there is a magic "PAGES_FOR_IO" #define, which is somewhat
> arbitrarily set to 4MB worth of pages. Where did that number come from?
> Who knows? But that's the number the code uses for the _initial_
> check of

I picked that up out of thin air. Intent there is to make sure small
(<100K, lets say) allocations will work during suspend.

> And the thing is, that "swsusp_shrink_memory()" is just full of
> heuristics. There's no hard numbers there. It doesn't seem to wait for
> writeout, it just does the equivalent of "shrink_list()" and
> "shrink_slab()", but it seems to have been basically cribbed half-way
> from the regular "try to free memory", without really doing it all.

akpm designed shrink_memory(). Long time ago it was just while (1)
kmalloc() loop. It should be waiting. Andrew?

> Just as an example: it does that "zone_is_all_unreclaimable()" logic that
> expects kswapd to mark things reclaimable again, but it doesn't seem to
> actually ever wait for kswapd or pdflush. It also seems to set
> "swappiness" to zero etc. Maybe it's all intentional, but it does mean
> that it uses some shared heuristics with the "real" VM, but uses them
> differently.

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html