On Wed 2009-12-02 22:25:16, Mel Gorman wrote: > On Wed, Dec 02, 2009 at 11:15:24PM +0100, Pavel Machek wrote: > > On Wed 2009-12-02 22:07:18, Mel Gorman wrote: > > > On Wed, Dec 02, 2009 at 10:11:07PM +0100, Pavel Machek wrote: > > > > On Wed 2009-12-02 14:28:12, Alan Jenkins wrote: > > > > > The original in-kernel suspend (swsusp) frees the in-memory hibernation > > > > > image before powering off the machine. s2disk doesn't, so there is > > > > > _much_ less free memory when it tries to power off. > > > > > > > > > > This is a gratuitous difference. The userspace suspend interface > > > > > /dev/snapshot only allows the hibernation image to be read once. > > > > > Once the s2disk program has read the last page, we can free the entire > > > > > image. > > > > > > > > > > This avoids a hang after writing the hibernation image which was > > > > > triggered by commit 5f8dcc21211a3d4e3a7a5ca366b469fb88117f61 > > > > > "page-allocator: split per-cpu list into one-list-per-migrate-type": > > > > > > > > Yes, you work around page-allocator hang. But is it right thing to do? > > > > > > > > > > What's wrong with it? The hang is likely because the allocator has no > > > memory to work with. The patch in question makes small changes to the > > > amount of available memory but it shouldn't matter on uni-core. Some > > > structures are slightly larger but it's extremely borderline. I'm at a > > > loss to explain actually why it makes a difference untill things were > > > extremely borderline to begin with. > > > > We reserve 4MB, for such purposes, and we already wrote image to disk > > with such constrains, so memory should not be _too_ tight. > > > > Can you try increasing PAGES_FOR_IO to 8MB or something like that? > > > > What's wrong with just freeing the memory that is no longer required? Nothing. But 4MB was enough to power down before, it is not enough now, and I'd like to understand why. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
