linux-kernel - Re: [PATCH] mm: add parameter to disable faultaround

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>] [day] [month] [year] [list]

Date:	Tue, 25 Nov 2014 03:40:16 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Chanho Min" <chanho.min@....com>
Cc:	"'Kirill A. Shutemov'" <kirill.shutemov@...ux.intel.com>,
	"'Hugh Dickins'" <hughd@...gle.com>,
	"'Michal Hocko'" <mhocko@...e.cz>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, "'HyoJun Im'" <hyojun.im@....com>,
	"'Gunho Lee'" <gunho.lee@....com>,
	"'Wonhong Kwon'" <wonhong.kwon@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] mm: add parameter to disable faultaround

On Tue, 25 Nov 2014 20:19:40 +0900 "Chanho Min" <chanho.min@....com> wrote:

> > > The faultaround improves the file read performance, whereas pages which
> > > can be dropped by drop_caches are reduced. On some systems, The amount of
> > > freeable pages under memory pressure is more important than read
> > > performance.
> > 
> > The faultaround pages *are* freeable.  Perhaps you meant "free" here.
> > 
> > Please tell us a great deal about the problem which you are trying to
> > solve.  What sort of system, what sort of workload, what is bad about
> > the behaviour which you are observing, etc.
> 
> We are trying to solve two issues.
> 
> We drop page caches by writing to /proc/sys/vm/drop_caches at specific point
> and make suspend-to-disk image. The size of this image is increased if faultaround
> is worked.

OK.

These pages are clean (mostly) and are mapped into process pagetables. 
Obviously mm/vmscan.c:shrink_all_memory() is not freeing these pages
prior to hibernating.

I forget what the policy/tuning is in this area.  IIRC, the intent of
shrink_all_memory() is to free up enough memory so that hibernation can
perform its function, rather than to explicitly reduce the size of the
image.

What I suggest you do is to take a look at how hibernation is calling
shrink_all_memory() and retune it so it shrinks a lot harder.  You may
want to disable swapping, or perhaps reduce it by performing one
shrink_all_memory() in the same way as at present, then perform a
second shrink_all_memory() more aggressively, but with
scan_control.may_swap=0.  The overall effect will be to make
hibernation tear down the process pagetable mappings and free these
pagecache pages before preparing the disk image.

If we can get this working then your hibernation image will be
significantly smaller than it is with this patch, because more pages
will be unmapped and freed.  There will of course be a lot of major
pagefaults after resume.  If that's a problem then perhaps we can tune
the second shrink_all_memory() pass to only unmap ptes for unreferenced
pages.

> Under memory pressure, we want to drop many page caches as possible.
> But, The number of dropped pages are reduced compared to non-faultaround kernel.

Again, why do you want to do this?  What problem is it solving?  I
assume you're using drop_caches for this as well?

Generally, any use of drop_caches is wrong, and indicates there's some
shortcoming in MM.

--
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/