From: Rik van Riel <riel@redhat.com>
To: Alex Thorlton <athorlton@sgi.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
Mel Gorman <mgorman@suse.de>,
Michel Lespinasse <walken@google.com>,
Benjamin LaHaise <bcrl@kvack.org>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andy Lutomirski <luto@amacapital.net>,
Al Viro <viro@zeniv.linux.org.uk>,
David Rientjes <rientjes@google.com>,
Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Jiang Liu <jiang.liu@huawei.com>,
Cody P Schafer <cody@linux.vnet.ibm.com>,
Glauber Costa <glommer@parallels.com>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC PATCH 2/3] Add tunable to control THP behavior
Date: Thu, 12 Dec 2013 16:37:11 -0500 [thread overview]
Message-ID: <52AA2C87.5040509@redhat.com> (raw)
In-Reply-To: <20131212180050.GC134240@sgi.com>
On 12/12/2013 01:00 PM, Alex Thorlton wrote:
> This part of the patch adds a tunable to
> /sys/kernel/mm/transparent_hugepage called threshold. This threshold
> determines how many pages a user must fault in from a single node before
> a temporary compound page is turned into a THP.
> +++ b/mm/huge_memory.c
> @@ -44,6 +44,9 @@ unsigned long transparent_hugepage_flags __read_mostly =
> (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)|
> (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>
> +/* default to 1 page threshold for handing out thps; maintains old behavior */
> +static int transparent_hugepage_threshold = 1;
I assume the motivation for writing all this code is that "1"
was not a good value in your tests.
That makes me wonder, why should 1 be the default value with
your patches?
If there is a better value, why should we not use that?
What is the upside of using a better value?
What is the downside?
Is there a value that would to bound the downside, so it
is almost always smaller than the upside?
--
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: Alex Thorlton <athorlton@sgi.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
Mel Gorman <mgorman@suse.de>,
Michel Lespinasse <walken@google.com>,
Benjamin LaHaise <bcrl@kvack.org>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andy Lutomirski <luto@amacapital.net>,
Al Viro <viro@zeniv.linux.org.uk>,
David Rientjes <rientjes@google.com>,
Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Jiang Liu <jiang.liu@huawei.com>,
Cody P Schafer <cody@linux.vnet.ibm.com>,
Glauber Costa <glommer@parallels.com>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC PATCH 2/3] Add tunable to control THP behavior
Date: Thu, 12 Dec 2013 16:37:11 -0500 [thread overview]
Message-ID: <52AA2C87.5040509@redhat.com> (raw)
In-Reply-To: <20131212180050.GC134240@sgi.com>
On 12/12/2013 01:00 PM, Alex Thorlton wrote:
> This part of the patch adds a tunable to
> /sys/kernel/mm/transparent_hugepage called threshold. This threshold
> determines how many pages a user must fault in from a single node before
> a temporary compound page is turned into a THP.
> +++ b/mm/huge_memory.c
> @@ -44,6 +44,9 @@ unsigned long transparent_hugepage_flags __read_mostly =
> (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)|
> (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>
> +/* default to 1 page threshold for handing out thps; maintains old behavior */
> +static int transparent_hugepage_threshold = 1;
I assume the motivation for writing all this code is that "1"
was not a good value in your tests.
That makes me wonder, why should 1 be the default value with
your patches?
If there is a better value, why should we not use that?
What is the upside of using a better value?
What is the downside?
Is there a value that would to bound the downside, so it
is almost always smaller than the upside?
next prev parent reply other threads:[~2013-12-12 21:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1386790423.git.athorlton@sgi.com>
2013-12-12 18:00 ` [RFC PATCH 1/3] Add flags for temporary compound pages Alex Thorlton
2013-12-12 18:00 ` Alex Thorlton
2013-12-12 18:00 ` [RFC PATCH 2/3] Add tunable to control THP behavior Alex Thorlton
2013-12-12 18:00 ` Alex Thorlton
2013-12-12 20:11 ` Andy Lutomirski
2013-12-12 20:11 ` Andy Lutomirski
2013-12-12 20:49 ` Alex Thorlton
2013-12-12 20:49 ` Alex Thorlton
2013-12-12 20:52 ` Andy Lutomirski
2013-12-12 20:52 ` Andy Lutomirski
2013-12-12 21:04 ` Alex Thorlton
2013-12-12 21:04 ` Alex Thorlton
2013-12-12 21:37 ` Rik van Riel [this message]
2013-12-12 21:37 ` Rik van Riel
2013-12-12 23:17 ` Alex Thorlton
2013-12-12 23:17 ` Alex Thorlton
2013-12-12 18:00 ` [RFC PATCH 3/3] Change " Alex Thorlton
2013-12-12 18:00 ` Alex Thorlton
2013-12-13 13:13 ` Kirill A. Shutemov
2013-12-13 13:13 ` Kirill A. Shutemov
2013-12-16 17:37 ` Alex Thorlton
2013-12-16 17:37 ` Alex Thorlton
2013-12-13 18:12 ` Oleg Nesterov
2013-12-13 18:12 ` Oleg Nesterov
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=52AA2C87.5040509@redhat.com \
--to=riel@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=athorlton@sgi.com \
--cc=bcrl@kvack.org \
--cc=benh@kernel.crashing.org \
--cc=cody@linux.vnet.ibm.com \
--cc=ebiederm@xmission.com \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=jiang.liu@huawei.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=luto@amacapital.net \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=viro@zeniv.linux.org.uk \
--cc=walken@google.com \
--cc=zhangyanfei@cn.fujitsu.com \
/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.