Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755497AbZDTMZJ (ORCPT ); Mon, 20 Apr 2009 08:25:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755216AbZDTMY4 (ORCPT ); Mon, 20 Apr 2009 08:24:56 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:57071 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754934AbZDTMYz (ORCPT ); Mon, 20 Apr 2009 08:24:55 -0400 Date: Tue, 7 Apr 2009 10:06:32 +0200 From: Pavel Machek To: Linus Torvalds Cc: Jens Axboe , Alan Jenkins , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton Subject: Re: [Bug #13058] First hibernation attempt fails Message-ID: <20090407080632.GG1408@ucw.cz> References: <20090417063007.GB4593@kernel.dk> <49E83DC4.8040207@tuffmail.co.uk> <20090417091321.GP4593@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2026 Lines: 44 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 -- 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/