From: Rik van Riel <riel@redhat.com>
To: David Rientjes <rientjes@google.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,
sasha.levin@oracle.com, hughd@google.com, hannes@cmpxchg.org,
vbabka@suse.cz, linux-kernel@vger.kernel.org,
aarcange@redhat.com
Subject: Re: [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of HPAGE_PMD_NR
Date: Fri, 27 Feb 2015 15:57:02 -0500 [thread overview]
Message-ID: <54F0DA1E.9060006@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1502271248240.2122@chino.kir.corp.google.com>
On 02/27/2015 03:53 PM, David Rientjes wrote:
> On Fri, 27 Feb 2015, Ebru Akagunduz wrote:
>
>> Using THP, programs can access memory faster, by having the
>> kernel collapse small pages into large pages. The parameter
>> max_ptes_none specifies how many extra small pages (that are
>> not already mapped) can be allocated when collapsing a group
>> of small pages into one large page.
>>
>
> Not exactly, khugepaged isn't "allocating" small pages to collapse into a
> hugepage, rather it is allocating a hugepage and then remapping the
> pageblock's mapped pages.
How would you describe the amount of extra memory
allocated, as a result of converting a partially
mapped 2MB area into a THP?
It is not physically allocating 4kB pages, but
I would like to keep the text understandable to
people who do not know the THP internals.
>> A larger value of max_ptes_none can cause the kernel
>> to collapse more incomplete areas into THPs, speeding
>> up memory access at the cost of increased memory use.
>> A smaller value of max_ptes_none will reduce memory
>> waste, at the expense of collapsing fewer areas into
>> THPs.
>>
>
> This changelog only describes what max_ptes_none does, it doesn't state
> why you want to change it from HPAGE_PMD_NR-1, which is 511 on x86_64
> (largest value, more thp), to HPAGE_PMD_NR/8, which is 64 (smaller value,
> less thp, less rss as a result of collapsing).
>
> This has particular performance implications on users who already have thp
> enabled, so it's difficult to change the default. This is tuanble that
> you could easily set in an initscript, so I don't think we need to change
> the value for everybody.
I think we do need to change the default.
Why? See this bug:
>> The problem was reported here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93111
Now, there may be a better value than HPAGE_PMD_NR/8, but
I am not sure what it would be, or why.
I do know that HPAGE_PMD_NR-1 results in undesired behaviour,
as seen in the bug above...
--
All rights reversed
--
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: David Rientjes <rientjes@google.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,
sasha.levin@oracle.com, hughd@google.com, hannes@cmpxchg.org,
vbabka@suse.cz, linux-kernel@vger.kernel.org,
aarcange@redhat.com
Subject: Re: [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of HPAGE_PMD_NR
Date: Fri, 27 Feb 2015 15:57:02 -0500 [thread overview]
Message-ID: <54F0DA1E.9060006@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1502271248240.2122@chino.kir.corp.google.com>
On 02/27/2015 03:53 PM, David Rientjes wrote:
> On Fri, 27 Feb 2015, Ebru Akagunduz wrote:
>
>> Using THP, programs can access memory faster, by having the
>> kernel collapse small pages into large pages. The parameter
>> max_ptes_none specifies how many extra small pages (that are
>> not already mapped) can be allocated when collapsing a group
>> of small pages into one large page.
>>
>
> Not exactly, khugepaged isn't "allocating" small pages to collapse into a
> hugepage, rather it is allocating a hugepage and then remapping the
> pageblock's mapped pages.
How would you describe the amount of extra memory
allocated, as a result of converting a partially
mapped 2MB area into a THP?
It is not physically allocating 4kB pages, but
I would like to keep the text understandable to
people who do not know the THP internals.
>> A larger value of max_ptes_none can cause the kernel
>> to collapse more incomplete areas into THPs, speeding
>> up memory access at the cost of increased memory use.
>> A smaller value of max_ptes_none will reduce memory
>> waste, at the expense of collapsing fewer areas into
>> THPs.
>>
>
> This changelog only describes what max_ptes_none does, it doesn't state
> why you want to change it from HPAGE_PMD_NR-1, which is 511 on x86_64
> (largest value, more thp), to HPAGE_PMD_NR/8, which is 64 (smaller value,
> less thp, less rss as a result of collapsing).
>
> This has particular performance implications on users who already have thp
> enabled, so it's difficult to change the default. This is tuanble that
> you could easily set in an initscript, so I don't think we need to change
> the value for everybody.
I think we do need to change the default.
Why? See this bug:
>> The problem was reported here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93111
Now, there may be a better value than HPAGE_PMD_NR/8, but
I am not sure what it would be, or why.
I do know that HPAGE_PMD_NR-1 results in undesired behaviour,
as seen in the bug above...
--
All rights reversed
next prev parent reply other threads:[~2015-02-27 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 18:26 [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of HPAGE_PMD_NR Ebru Akagunduz
2015-02-27 18:26 ` Ebru Akagunduz
2015-02-27 20:53 ` David Rientjes
2015-02-27 20:53 ` David Rientjes
2015-02-27 20:57 ` Rik van Riel [this message]
2015-02-27 20:57 ` Rik van Riel
2015-02-27 21:12 ` David Rientjes
2015-02-27 21:12 ` David Rientjes
2015-03-02 14:00 ` Vlastimil Babka
2015-03-02 14:00 ` Vlastimil Babka
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=54F0DA1E.9060006@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.