linux-kernel - Re: [PATCH 0/3] swsusp: shrink file cache first

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200902070039.54402.rjw@sisk.pl>
Date:	Sat, 7 Feb 2009 00:39:53 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	hannes@...xchg.org
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 0/3] swsusp: shrink file cache first

> Hello!

Hi Hannes,
 
> here are three patches that adjust the memory shrinking code used for
> suspend-to-disk.
> 
> The first two patches are cleanups only and can probably go in
> regardless of the third one.
> 
> The third patch changes the shrink_all_memory() logic to drop the file
> cache first before touching any mapped files and only then goes for
> anon pages.
> 
> The reason is that everything not shrunk before suspension has to go
> into the image and will be 'prefaulted' before the processes can
> resume and the system is usable again, so the image should be small
> and contain only pages that are likely to be used right after resume
> again.  And this in turn means that the inactive file cache is the
> best point to start decimating used memory.
> 
> Also, right now, subsequent faults of contiguously mapped files are
> likely to perform better than swapin (see
> http://kernelnewbies.org/KernelProjects/SwapoutClustering), so not
> only file cache is preferred over other pages, but file pages over
> anon pages in general.
> 
> Testing up to this point shows that the patch does what is intended,
> shrinking file cache in favor of anon pages.  But whether the idea is
> correct to begin with is a bit hard to quantify and I am still working
> on it, so RFC only.

Thanks a lot for the patches, I'll review them as soon as I can.

I've got them with broken headers, but that's not a big deal.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/