Re: swsusp: allow resume from initramfs

[Pavel Machek]

Hi!

> > Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
> > thats bad, I wanted that one to be shared most).
> 
> Mmm. As you might remember, I used extents from 1.0 to save space. The
> feedback from the last submission to LKML about getting rid of the
> page_alloc.c hooks made me re-examine the use of the memory pool, which
> made me re-examine the format in which the data was stored. Switching to
> bitmaps meant that after saving the LRU pages, I can recalculate what
> remains to be saved without ever changing the result in the process.
> (Using extents, there was a small chance that the recalculated metadata
> would require an extra extent on an extra page, which means you have to
> recalculate everything again :<. With discontiguous bitmaps, I get
> efficient storage, no need for > order zero allocations and no feedback
> whatsoever when recalculating image metadata. Besides removing the
> memory pool code, I've already removed some more, and am about to
> simplify the code for the remaining extents (for storage metadata). I
> hope to also be able to further simplify the image preparation code too.
> 
> All that to say "Bitmaps were a definite win!". Perhaps I can sell you
> on the advantages of using them :>

Not sure, if one bit goes wrong you put everything in the wrong places
:-). Linklist seems just okay to me, no > 4K allocations. I'm not sure
why recalculation is that big problem.

> By the way, did you see the effect of the memory eating patch? I didn't
> think about it until someone emailed me, but the improvement was 50x
> speed in the best case!

Well, more interesting was that you actually freed much more memory
with your patch. *You actually made memory freeing to work*. So yes, I
like that one.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/