linux-kernel - Re: [PATCH] mm: incorporate zero pages into transparent huge pages

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]

Date:	Tue, 10 Feb 2015 21:26:39 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Andrea Arcangeli <aarcange@...hat.com>,
	Ebru Akagunduz <ebru.akagunduz@...il.com>
CC:	linux-mm@...ck.org, akpm@...ux-foundation.org,
	kirill@...temov.name, mhocko@...e.cz, mgorman@...e.de,
	rientjes@...gle.com, sasha.levin@...cle.com, hughd@...gle.com,
	hannes@...xchg.org, vbabka@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: incorporate zero pages into transparent huge pages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/2015 04:06 PM, Andrea Arcangeli wrote:
> On Tue, Feb 10, 2015 at 12:47:37AM +0200, Ebru Akagunduz wrote:
>> This patch improves THP collapse rates, by allowing zero pages.
>> 
>> Currently THP can collapse 4kB pages into a THP when there are up
>> to khugepaged_max_ptes_none pte_none ptes in a 2MB range.  This
>> patch counts pte none and mapped zero pages with the same
>> variable.
>> 
>> The patch was tested with a program that allocates 800MB of 
>> memory, and performs interleaved reads and writes, in a pattern 
>> that causes some 2MB areas to first see read accesses, resulting 
>> in the zero pfn being mapped there.
>> 
>> To simulate memory fragmentation at allocation time, I modified 
>> do_huge_pmd_anonymous_page to return VM_FAULT_FALLBACK for read 
>> faults.
>> 
>> Without the patch, only %50 of the program was collapsed into THP
>> and the percentage did not increase over time.
>> 
>> With this patch after 10 minutes of waiting khugepaged had 
>> collapsed %89 of the program's memory.
> 
> This is very good idea, associating it with the sysctl is sensible 
> here as collapsing zeropages would affect the memory footprint in
> the same way as none ptes.
> 
> __collapse_huge_page_copy however is likely screwing with the 
> refcounts of the zero page. Did you have DEBUG_VM=y enabled? If
> yes you should get one warning that the zeropage refcount
> underflowed that could confirm my concern:

In __collapse_huge_page_copy, the zero pte takes the same path
as pte_none, so I believe that part of the code is correct.

> So in short I think __collapse_huge_page_copy and
> release_pte_pages needs an additional case that complements the
> already existing special

You are right that release_pte_pages needs a special case too,
in order to skip refcounting on the zero page.

Ebru?

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU2r3fAAoJEM553pKExN6DJPAH/1TT9uzS0/1wRcN7gn/UP0rb
TpkKzihDOeQgEPfGjd6wUgepU0iVhMX80qBCqk0wIAPgZLnt4IxSl24f09Sm38Cn
zAV0mLySmoaYNisf+qieZ/NF/PDiUOrxGzWJzvm7Ymqq8Mh94qdgpsLy2I+EQioT
RqwbYMMB2XvH3mWOzhQUfnyG5mJMmZtpVcrJ4MIVVq5a3x+Ry668ZT75oNegni5W
Hfax6/8jf4Bjpxc9I/9FvZXzZr9m9yVcGHoCckdGxlnsSSgd60B9b+EYy6AlJpqS
xYkGhKSL0iAAoXYkmrtFdLpdhU/eqhgLb0V2NxcimjrzNG/0LE8fGhb/0SmPXUU=
=085q
-----END PGP SIGNATURE-----
--
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/