From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753002AbcHOOeD (ORCPT ); Mon, 15 Aug 2016 10:34:03 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:50036 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621AbcHOOeB (ORCPT ); Mon, 15 Aug 2016 10:34:01 -0400 Date: Mon, 15 Aug 2016 16:33:49 +0200 From: Pavel Machek To: "Rafael J. Wysocki" Cc: Linux PM list , Linux Kernel Mailing List Subject: Re: [PATCH v2 3/3] PM / hibernate: Recycle safe pages after image restoration Message-ID: <20160815143349.GB29447@amd> References: <2260927.OOWMYX738E@vostro.rjw.lan> <2448424.sR3JM3oiG3@vostro.rjw.lan> <20160811210615.GA28618@amd> <3432840.yEuDW8huOO@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3432840.yEuDW8huOO@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2016-08-11 23:23:20, Rafael J. Wysocki wrote: > On Thursday, August 11, 2016 11:06:15 PM Pavel Machek wrote: > > Hi! > > > > > From: Rafael J. Wysocki > > > > > > One of the memory bitmaps used by the hibernation image restoration > > > code is freed after the image has been loaded. > > > > > > That is not quite efficient, though, because the memory pages used > > > for building that bitmap are known to be safe (ie. they were not > > > used by the image kernel before hibernation) and the arch-specific > > > code finalizing the image restoration may need them. In that case > > > it needs to allocate those pages again via the memory management > > > subsystem, check if they are really safe again by consulting the > > > other bitmaps and so on. > > > > > > To avoid that, recycle those pages by putting them into the global > > > list of known safe pages so that they can be given to the arch code > > > right away when necessary. > > > > Ok, so you are trying to gain speed here? How much is the speedup? > > This is more about making it easier to debug than about speed, TBH. > > Avoiding bitmap operations and the mm subsystem involvement reduces > complexity and the number of places to look into in case something goes > wrong. Well, it looked like 3/3 just added code and did not remove anything, so I fail to see how it makes code easier to follow... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html