From: Rik van Riel <riel@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>,
Ebru Akagunduz <ebru.akagunduz@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
kirill@shutemov.name, mhocko@suse.cz, mgorman@suse.de,
rientjes@google.com, sasha.levin@oracle.com, hughd@google.com,
hannes@cmpxchg.org, vbabka@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: incorporate zero pages into transparent huge pages
Date: Tue, 10 Feb 2015 21:26:39 -0500 [thread overview]
Message-ID: <54DABDDF.3030402@redhat.com> (raw)
In-Reply-To: <20150210210657.GI11755@redhat.com>
-----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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>,
Ebru Akagunduz <ebru.akagunduz@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
kirill@shutemov.name, mhocko@suse.cz, mgorman@suse.de,
rientjes@google.com, sasha.levin@oracle.com, hughd@google.com,
hannes@cmpxchg.org, vbabka@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: incorporate zero pages into transparent huge pages
Date: Tue, 10 Feb 2015 21:26:39 -0500 [thread overview]
Message-ID: <54DABDDF.3030402@redhat.com> (raw)
In-Reply-To: <20150210210657.GI11755@redhat.com>
-----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-----
next prev parent reply other threads:[~2015-02-11 2:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 22:47 [PATCH] mm: incorporate zero pages into transparent huge pages Ebru Akagunduz
2015-02-09 22:47 ` Ebru Akagunduz
2015-02-10 21:06 ` Andrea Arcangeli
2015-02-10 21:06 ` Andrea Arcangeli
2015-02-11 2:26 ` Rik van Riel [this message]
2015-02-11 2:26 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DABDDF.3030402@redhat.com \
--to=riel@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebru.akagunduz@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=rientjes@google.com \
--cc=sasha.levin@oracle.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.