> Here's more up-to-date version: https://lkml.org/lkml/2012/8/20/337
These don't seem to give us a noticeable performance change either:
With THP:
real22m34.279s
user10797m35.984s
sys 39m18.188s
Without THP:
real4m48.957s
user2118m23.208s
sys 113m12.740s
Looks like we
page fault rates are
actually better on this threaded test than in the non-threaded case!
- Alex
On Fri, Sep 27, 2013 at 04:16:17PM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton noticed that some massively threaded workloads work poorly,
> if THP enabled. This patchset fixes this by
On Fri, Oct 04, 2013 at 11:26:02PM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton wrote:
> > Kirill,
> >
> > I've pasted in my results for 512 cores below. Things are looking
> > really good here. I don't have a test for HUGETLBFS, but if you want to
&g
On Mon, Sep 16, 2013 at 02:25:31PM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton noticed that some massivly threaded workloads work poorly,
> if THP enabled. This patchset fixes this by introducing split page table
> lock for PMD tables. hugetlbfs is not covered yet.
>
> This pa
On Tue, Aug 27, 2013 at 12:01:01PM -0500, Robin Holt wrote:
> Alex,
>
> Although the explanation seems plausible, have you verified this is
> actually possible? You could make a simple pthread test case which
> allocates a getpagesize() * area, prints its
> address and then each thread migrate a
> Robin,
>
> I tweaked one of our other tests to behave pretty much exactly as I
> - malloc a large array
> - Spawn a specified number of threads
> - Have each thread touch small, evenly spaced chunks of the array (e.g.
> for 128 threads, the array is divided into 128 chunks, and each thread
>
On Thu, Sep 05, 2013 at 05:27:46PM -0400, Naoya Horiguchi wrote:
> Thp related code also uses per process mm->page_table_lock now.
> So making it fine-grained can provide better performance.
>
> This patch makes thp support split page table lock by using page->ptl
> of the pages storing "pmd_trans
On Mon, Sep 09, 2013 at 10:34:45AM +0800, Daniel J Blueman wrote:
> On Saturday, 7 September 2013 02:10:02 UTC+8, Naoya Horiguchi wrote:
> >Hi Alex,
> >
> >On Fri, Sep 06, 2013 at 11:04:23AM -0500, Alex Thorlton wrote:
> >> On Thu, Sep 05, 2013 at 05:27:46P
On Thu, Sep 05, 2013 at 01:15:10PM +0200, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > > Robin,
> > >
> > > I tweaked one of our other tests to behave pretty much exactly as I
> > > - malloc a large array
> > > - Spawn a specified
On Mon, Oct 07, 2013 at 12:48:20PM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton wrote:
> > > > Sorry for the delay on these results. I hit some strange issues with
> > > > running thp_memscale on systems with either of the following
> > > > co
This patch changes out the page_table_lock for the pud_page ptl in the
THP fault path; pretty self-explanatory. I got lazy and commented out
the spinlock assertion in follow_trans_huge_pmd instead of digging up
the pud_page ptl in this function. This is just a proof of concept, so
I didn't feel t
locked things appropriately.
As a side note, we still have some pretty significant scaling issues
with this test, both with THP on, and off. I'm cleaning up the locking
here first as this is causing the biggest performance hit.
Alex Thorlton (1):
Change THP code to use pud_page(
> Let me guess: you have HUGETLBFS enabled in your config, right? ;)
>
> HUGETLBFS hasn't converted to new locking and we disable split pmd lock if
> HUGETLBFS is enabled.
Ah, that's got it! I double checked my config a million times to
make sure that I wasn't going crazy, but I must've miss
On Fri, Sep 27, 2013 at 12:38:07AM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton wrote:
> > > Let me guess: you have HUGETLBFS enabled in your config, right? ;)
> > >
> > > HUGETLBFS hasn't converted to new locking and we disable split pmd lock if
> >
On Fri, Sep 27, 2013 at 12:42:46AM +0300, Kirill A. Shutemov wrote:
> Kirill A. Shutemov wrote:
> > Alex Thorlton wrote:
> > > > Let me guess: you have HUGETLBFS enabled in your config, right? ;)
> > > >
> > > > HUGETLBFS hasn't converted to new
Kirill,
I've merged a couple of our e-mails together for this reply:
On Fri, Sep 20, 2013 at 03:31:37PM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton noticed that some massivly threaded workloads work poorly,
> if THP enabled. This patchset fixes this by introducing split page t
On Tue, Jun 11, 2013 at 03:20:09PM -0700, David Rientjes wrote:
> On Tue, 11 Jun 2013, Alex Thorlton wrote:
>
> > This patch adds the ability to control THPs on a per cpuset basis.
> > Please see
> > the additions to Documentation/cgroups/cpusets.txt for more
> >
This patch adds the ability to control THPs on a per cpuset basis. Please see
the additions to Documentation/cgroups/cpusets.txt for more information.
Signed-off-by: Alex Thorlton
Reviewed-by: Robin Holt
Cc: Li Zefan
Cc: Rob Landley
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Rik van Riel
Cc
On Tue, Jun 11, 2013 at 09:55:18AM +0300, Kirill A. Shutemov wrote:
> Alex Thorlton wrote:
> > This patch adds the ability to control THPs on a per cpuset basis. Please
> > see
> > the additions to Documentation/cgroups/cpusets.txt for more information.
> >
>
This patch adds the ability to control THPs on a per cpuset basis. Please see
the additions to Documentation/cgroups/cpusets.txt for more information.
Signed-off-by: Alex Thorlton
Reviewed-by: Robin Holt
Cc: Li Zefan
Cc: Rob Landley
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Rik van Riel
Cc
ting/progs/thp_benchmarks/321.equake_l>
time ./run.sh
...
Done. Terminating the simulation.
real4m52.502s
user2127m18.548s
sys 104m50.828s
Working on getting some more information about the root of the
performance issues now...
Alex Thorlton (8):
THP: Use real addres
Conflicts:
mm/huge_memory.c
---
mm/huge_memory.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 55ec681..2e6f106 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -701,7 +701,8 @@ static inline pmd_t mk_huge_pmd(
---
arch/x86/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a088ed7..d3f6dc7 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1233,7 +1233,7 @@ do_page_fault(struct pt_regs *regs, unsigned long
error_cod
---
arch/x86/lib/clear_page_nocache_64.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/clear_page_nocache_64.S
b/arch/x86/lib/clear_page_nocache_64.S
index a6d938c..d03408e 100644
--- a/arch/x86/lib/clear_page_nocache_64.S
+++ b/arch/x86/lib/clear_page_n
---
arch/x86/lib/clear_page_nocache_64.S | 91 ++--
1 file changed, 77 insertions(+), 14 deletions(-)
diff --git a/arch/x86/lib/clear_page_nocache_64.S
b/arch/x86/lib/clear_page_nocache_64.S
index ee16d15..a6d938c 100644
--- a/arch/x86/lib/clear_page_nocache_64.S
---
mm/memory.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 1ce2e2a..69a5a38 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4249,16 +4249,17 @@ void clear_huge_page(struct page *page,
unsigned long addr, unsigned int
---
mm/huge_memory.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a92012a..55ec681 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -746,11 +746,11 @@ static inline gfp_t alloc_hugepage_gfpmask(int defrag,
gfp_t extra
Conflicts:
arch/x86/mm/fault.c
---
arch/x86/include/asm/page.h | 2 ++
arch/x86/include/asm/string_32.h | 5 +
arch/x86/include/asm/string_64.h | 5 +
arch/x86/lib/Makefile| 1 +
arch/x86/lib/clear_page_nocache_32.S | 30
---
mm/memory.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 69a5a38..17d61f0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4231,18 +4231,35 @@ EXPORT_SYMBOL(might_fault);
#endif
#if defined(CONFIG_TRANSPAREN
> This 321.equake_l thing is not public, right? Do you have anything
> that
> is public that shows the same problem?
The quake test comes from the SPEC OMP benchmarks. While I believe this
suite is available to anybody, I don't think it's free. I was given
the test by our benchmarking team, I'll
> Could you add some actual descriptions to these patches that say why you
> are doing this, and why this particular patch is needed and implemented
> this way?
>
> You mention that THP is slow for you, then go on to implement some
> non-cached page zero'ing, but you never quite connect the dots.
On Fri, Aug 16, 2013 at 09:46:35PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 16, 2013 at 01:17:28PM -0500, Alex Thorlton wrote:
> > I actually didn't write these patches (made a few tweaks to get them
> > running on the latest kernel though). They were submitted last July by
We've re-evaluated the need for a patch to support some sort of finer
grained control over thp, and, based on some tests performed by our
benchmarking team, we're seeing that we'd definitely still like to
implement some method to support this. Here's an e-mail from John
Baron (jba...@sgi.com), o
This patch implements functionality to allow processes to disable the use of
transparent hugepages through the prctl syscall.
We've determined that some jobs perform significantly better with thp disabled,
and we need a way to control thp on a per-process basis, without relying on
madvise.
---
i
> Instead of blowing a whole int on this bool, we could add it
> to the bitfield a few pages up where we have other prctl things like..
>
> unsigned no_new_privs:1;
Definitely a better way to go. I'll tweak that and float another
version of the patch. Thanks for the input, Dave!
--
To uns
> What kind of workloads are you talking about?
Our benchmarking team has a list of several of the SPEC OMP benchmarks
that perform significantly better when THP is disabled. I tried to get
the list but one of our servers is acting up and I can't get to it
right now :/
> What's wrong with madvise
This patch implements functionality to allow processes to disable the use of
transparent hugepages through the prctl syscall.
We've determined that some jobs perform significantly better with thp disabled,
and we needed a way to control thp on a per-process basis, without relying on
madvise.
v2 -
think the changelog should explain why madvise() is bad.
No problem. I wanted to keep it simple for the original submission, but
that's probably something that should be included.
> But I simply can't understand why this flag is per-thread. It should
> be
> mm flag, no?
This is something that
> Please try it with the vclear patches.
Thanks, Andi. I'll give that a shot and see if it makes any difference.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
> It would be good to describe which jobs and why thp cannot be fixed for
> these.
I'm going to see if I can get the benchmarks that are causing trouble up
and running on my own to get some more information (problem was
originally identified by our benchmarking team).
Thanks for the input!
- Ale
> What everyone else said, plus...
>
> I worry about the inherit-across-fork thing. A scenario we should
> think about is where the user doesn't build his own executables. So he
> writes a little wrapper which runs prctl(PR_SET_THP_DISABLED, 0) then
> execs the third-party-app. But what happens
On Mon, Aug 01, 2016 at 02:49:57PM +0100, Matt Fleming wrote:
> On Tue, 26 Jul, at 05:38:33PM, Alex Thorlton wrote:
> > This problem has actually been in the UV code for a while, but we didn't
> > catch it until recently, because we had been relying on EFI_OLD_MEMMAP
> &g
On Mon, Aug 01, 2016 at 02:39:26PM +0100, Matt Fleming wrote:
> On Tue, 26 Jul, at 05:38:32PM, Alex Thorlton wrote:
> >
> > After investigating the problem here and figuring out the proper way to
> > get the noefi parameter working again, I noticed that there appears to
&
On Thu, Aug 04, 2016 at 10:25:32AM +0100, Matt Fleming wrote:
> On Mon, 01 Aug, at 09:34:10AM, Alex Thorlton wrote:
> >
> > Hmm... That's a good point. It certainly would be nice for us to have
> > those mappings in the kexec kernel, at least for the time being. If
first __map_region
that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping").
Signed-off-by: Alex Thorlton
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Mike Travis
Cc: Matt Fleming
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H.
Hey guys,
We've been hitting issues with machines with 4096 or more logical cores
hanging up at clocksource_done_booting, seemingly forever. The problem
occurs somewhat intermittently, though it hits more consistently as you
increase the core count. We've observed this problem on kernels
startin
On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote:
> I can provide full logs if desired.
Full log is here:
http://oss.sgi.com/projects/athorlton/harp50-6144-nortc
I'd use wget to download it. Probably don't want to try to open the 15M
file in your browser :)
Also,
On Mon, Aug 31, 2015 at 10:32:50PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote:
> q
> > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> > index fd643d8..8502521 100644
> > --- a/kernel/stop_machine.c
> &g
On Mon, Aug 31, 2015 at 11:12:12PM +0200, Thomas Gleixner wrote:
> On Mon, 31 Aug 2015, Alex Thorlton wrote:
> > I was able to hit this issue on 4.2-rc1 with our RTC disabled, to rule
> > out any scaling issues related to multiple concurrent reads to our
> > RTC's MMR.
&g
On Sat, Dec 06, 2014 at 03:14:45PM -0500, James Smart wrote:
> Myself and several others here at Emulex maintain the code. The
> recommendations look fine. Feel free to post something if you beat
> us to the work.
Great! Thanks for letting me know, James. I will probaby have some
time to look
On Mon, Dec 08, 2014 at 11:42:14AM +0100, Ingo Molnar wrote:
> This patch fails to build with certain configs:
>
> kernel/sched/core.c:7130:33: error: incompatible types when assigning to type
> ‘cpumask_var_t’ from type ‘void *’
Thanks for letting us know, Ingo. I believe George has something
On Thu, Dec 04, 2014 at 12:34:04AM +0100, Thomas Gleixner wrote:
> first of all, could you please format your mail so it is actually
> readable and can be replied to?
My fault there - stupid mistake.
> If you would provide real data instead of half baken assumptions
> we might actually be able to
This patch adds a VM_INIT_DEF_MASK, to allow us to set the default flags
for VMs. It also adds a prctl control which alllows us to set the THP
disable bit in mm->def_flags so that VMs will pick up the setting as
they are created.
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
roach. One could also say that it would have
been better to do it this way right from the beginning...
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Andrew Morton
Cc: Paolo Bonzini
Cc: &quo
load_elf_binary() sets current->mm->def_flags = def_flags and
def_flags is always zero. Not only this looks strange, this is
unnecessary because mm_init() has already set ->def_flags = 0.
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwid
d_mmprctlv3.tar.gz
Let me know if anybody has any further suggestions here. Thanks!
(Sorry for the big cc list!)
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Andrew Morton
Cc: Paolo Bon
On Tue, Feb 25, 2014 at 02:54:03PM -0600, Alex Thorlton wrote:
> (First send had too big of a cc list to make it into all the mailing lists.)
Sorry for the double-send to a couple of lists/people. I got bumped
from linux-api for having too long of a cc list, and I figured it had
gotten bum
On Wed, Feb 26, 2014 at 05:57:59PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 26, 2014 at 04:31:44PM +0100, Oleg Nesterov wrote:
> Do we want a comment here, explaining why s390 is special again?
Here's what I've got, with everybody's suggestions spun together:
diff --git a/mm/huge_memory.c b/mm/
On Wed, Feb 26, 2014 at 08:27:36PM +0100, Christian Borntraeger wrote:
> On 26/02/14 19:06, Oleg Nesterov wrote:
> > On 02/26, Alex Thorlton wrote:
> >>
> >> + * MADV_HUGEPAGE after PRCTL_THP_DISABLE is broken on s390 because
> >> + * qemu blindly does madvise(
On Mon, Nov 04, 2013 at 02:58:28PM +, Mel Gorman wrote:
> On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote:
> > Hi guys,
> >
> > I ran into a bug a week or so ago, that I believe has something to do
> > with NUMA balancing, but I'm having a
On Wed, Feb 26, 2014 at 03:24:34PM -0800, Andrew Morton wrote:
> On Wed, 26 Feb 2014 13:39:17 -0600 Alex Thorlton wrote:
>
> > >
> > >
> > > > I'd suggest the patch below on top of your changes, but I won't argue.
> >
> > I like thi
roach. One could also say that it would have
been better to do it this way right from the beginning...
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Andrew Morton
Cc: Paolo Bonzini
Cc: &quo
advise, we
simply ignore the call (return 0).
Reported-by: Christian Borntraeger
Suggested-by: Paolo Bonzini
Suggested-by: Oleg Nesterov
Signed-off-by: Alex Thorlton
Cc: Gerald Schaefer
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Andrew Morton
Cc: Paolo Bonzini
On Wed, Feb 26, 2014 at 06:01:53PM -0600, Alex Thorlton wrote:
> On Wed, Feb 26, 2014 at 03:24:34PM -0800, Andrew Morton wrote:
> > On Wed, 26 Feb 2014 13:39:17 -0600 Alex Thorlton wrote:
> >
> > > >
> > > >
> > > > > I'd sugges
p://oss.sgi.com/projects/memtests/thp_pthread_mmprctlv3.tar.gz
Let me know if anybody has any further suggestions here. Thanks!
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Andrew Morto
This patch adds a VM_INIT_DEF_MASK, to allow us to set the default flags
for VMs. It also adds a prctl control which alllows us to set the THP
disable bit in mm->def_flags so that VMs will pick up the setting as
they are created.
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
load_elf_binary() sets current->mm->def_flags = def_flags and
def_flags is always zero. Not only this looks strange, this is
unnecessary because mm_init() has already set ->def_flags = 0.
Signed-off-by: Alex Thorlton
Suggested-by: Oleg Nesterov
Cc: Gerald Schaefer
Cc: Martin Schwid
On Thu, Feb 06, 2014 at 12:15:40AM +0100, Borislav Petkov wrote:
> On Wed, Feb 05, 2014 at 03:45:36PM -0600, Alex Thorlton wrote:
> > While working on an answer to this question, I ran across another issue
> > on some newer hardware, that looks like it's definitely related to t
THPs are set to "madvise," as well as
making sure that VM_HUGEPAGE is set for this vma.
Signed-off-by: Alex Thorlton
Reported-by: Alex Thorlton
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Rik van Riel
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kern
On Wed, Jan 22, 2014 at 10:26:21AM +, Mel Gorman wrote:
> On Tue, Jan 14, 2014 at 01:38:01PM -0600, Alex Thorlton wrote:
> > On Tue, Jan 14, 2014 at 03:44:57PM +, Mel Gorman wrote:
> > > On Fri, Jan 10, 2014 at 04:39:09PM -0600, Alex Thorlton wrote:
> > > >
On Tue, Jan 21, 2014 at 03:24:08PM -0800, David Rientjes wrote:
> On Tue, 21 Jan 2014, Alex Thorlton wrote:
>
> > hugepage_vma_check is called during khugepaged_scan_mm_slot to ensure
> > that khugepaged doesn't try to allocate THPs in vmas where they are
> > disallo
On Wed, Jan 22, 2014 at 06:45:53PM +0100, Oleg Nesterov wrote:
> Alex, Andrew, I think this simple series makes sense in any case,
> but _perhaps_ it can also help THP_DISABLE.
>
> On 01/20, Alex Thorlton wrote:
> >
> > On Mon, Jan 20, 2014 at 09:15:25PM +0
On Wed, Jan 22, 2014 at 08:43:27PM +0100, Oleg Nesterov wrote:
> On 01/22, Oleg Nesterov wrote:
> >
> > On 01/22, Alex Thorlton wrote:
> > > > + case PR_SET_THP_DISABLE:
> > > > + case PR_GET_THP_DISABLE:
> > > > + down_w
We've been hitting the following bug in the latest kernel, during boot:
kernel BUG at arch/x86/mm/init_64.c:351!
invalid opcode: [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-medusa-04156-g90804ed-dirty
#750
Hardware name: Intel Corp. Stoutland Platform, BIOS 2
so have THP disabled. This may not be the desired behavior.
Signed-off-by: Alex Thorlton
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Benjamin Herrenschmidt
Cc: Rik van Riel
Cc: Naoya Horiguchi
Cc: Oleg Nesterov
Cc: "Eric W. Bieder
On Fri, Jan 10, 2014 at 10:23:10PM +0200, Kirill A. Shutemov wrote:
> Do you know what cause the difference? I prefer to fix THP instead of
> adding new knob to disable it.
The issue is that when you touch 1 byte of an untouched, contiguous 2MB
chunk, a THP will be handed out, and the THP will be
On Fri, Jan 10, 2014 at 11:10:10PM +0100, Peter Zijlstra wrote:
> We already have the information to determine if a page is shared across
> nodes, Mel even had some prototype code to do splits under those
> conditions.
I'm aware that we can determine if pages are shared across nodes, but I
thought
On Sat, Jan 11, 2014 at 04:53:37PM +0100, Oleg Nesterov wrote:
> On 01/10, Alex Thorlton wrote:
> >
> > This patch adds an mm flag (MMF_THP_DISABLE) to disable transparent
> > hugepages using prctl. It is based on my original patch to add a
> > per-task_struct flag t
On Sat, Nov 23, 2013 at 12:09:24AM +, Mel Gorman wrote:
> On Fri, Nov 22, 2013 at 11:05:24PM +, Mel Gorman wrote:
> > On Fri, Nov 22, 2013 at 03:28:07PM -0600, Alex Thorlton wrote:
> > > > If the warning added by that patch does *not* trigger than can you also
> &
On Sun, Jan 12, 2014 at 02:56:00PM +0100, Oleg Nesterov wrote:
> On 01/11, Alex Thorlton wrote:
> >
> > On Sat, Jan 11, 2014 at 04:53:37PM +0100, Oleg Nesterov wrote:
> >
> > > I simply can't understand, this all looks like overkill. Can't yo
On Tue, Jan 14, 2014 at 03:44:57PM +, Mel Gorman wrote:
> On Fri, Jan 10, 2014 at 04:39:09PM -0600, Alex Thorlton wrote:
> > On Fri, Jan 10, 2014 at 11:10:10PM +0100, Peter Zijlstra wrote:
> > > We already have the information to determine if a page is shared across
> &g
On Wed, Nov 06, 2013 at 01:10:48PM +, Mel Gorman wrote:
> On Mon, Nov 04, 2013 at 02:03:46PM -0600, Alex Thorlton wrote:
> > On Mon, Nov 04, 2013 at 02:58:28PM +, Mel Gorman wrote:
> > > On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote:
> > > > H
On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote:
> Hi guys,
>
> I ran into a bug a week or so ago, that I believe has something to do
> with NUMA balancing, but I'm having a tough time tracking down exactly
> what is causing it. When running with the fol
On Fri, Nov 08, 2013 at 11:20:54AM +, Mel Gorman wrote:
> On Thu, Nov 07, 2013 at 03:48:38PM -0600, Alex Thorlton wrote:
> > > Try the following patch on top of 3.12. It's a patch that is expected to
> > > be merged for 3.13. On its own it'll hurt automatic NUMA
On Fri, Nov 08, 2013 at 04:13:29PM -0600, Alex Thorlton wrote:
> On Fri, Nov 08, 2013 at 11:20:54AM +, Mel Gorman wrote:
> > On Thu, Nov 07, 2013 at 03:48:38PM -0600, Alex Thorlton wrote:
> > > > Try the following patch on top of 3.12. It's a patch that is expecte
Hi guys,
I ran into a bug a week or so ago, that I believe has something to do
with NUMA balancing, but I'm having a tough time tracking down exactly
what is causing it. When running with the following configuration
options set:
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT
On Thu, Oct 17, 2013 at 07:30:58PM +0800, Bob Liu wrote:
> Hi Alex,
>
> On Wed, Oct 16, 2013 at 11:54 PM, Alex Thorlton wrote:
> > Hi guys,
> >
> > I ran into a bug a week or so ago, that I believe has something to do
> > with NUMA balancing, but I'm hav
> If the warning added by that patch does *not* trigger than can you also
> test this patch? It removes the barriers which should not be necessary
> and takes a reference tot he page before waiting on the lock. The
> previous version did not take the reference because otherwise the
> WARN_ON could
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.
Signed-off-by: Alex Thorlton
Cc: Andrew Morton
Cc: Nate Zimmer
I'll rebase it as soon as some of the remaining issues have
been sorted out, this will also mean changing over to the split PTL
where appropriate.
Signed-off-by: Alex Thorlton
Cc: Andrew Morton
Cc: Nate Zimmer
Cc: Cliff Wickman
Cc: "Kirill A. Shutemov"
Cc: Benjamin Herrenschmi
a bit more for later versions
I've left most of my comments in here just to provide people with some
insight into what I may have been thinking when I chose to do something
in a certain way. These will probably be trimmed down in later versions
of the patch.
Signed-off-by: Alex Thorlton
pages from the chunk.
Signed-off-by: Alex Thorlton
Cc: Andrew Morton
Cc: Nate Zimmer
Cc: Cliff Wickman
Cc: "Kirill A. Shutemov"
Cc: Benjamin Herrenschmidt
Cc: Rik van Riel
Cc: Wanpeng Li
Cc: Mel Gorman
Cc: Michel Lespinasse
Cc: Benjamin LaHaise
Cc: Oleg Nesterov
Cc: "Er
Ugggh. Looks like mutt clobbered the message ID on the cover letter,
screwing up the reply chain. Sorry about that :/
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
> Is there a setting that will turn off the must-be-the-same-node
> behavior? There are workloads where TLB matters more than cross-node
> traffic (or where all the pages are hopelessly shared between nodes,
> but hugepages are still useful).
That's pretty much how THPs already behave in the kern
> Right. I like that behavior for my workload. (Although I currently
> allocate huge pages -- when I wrote that code, THP interacted so badly
> with pagecache that it was a non-starter. I think it's fixed now,
> though.)
In that case, it's probably best to just stick with current behavior,
and
On Thu, Dec 12, 2013 at 04:37:11PM -0500, Rik van Riel wrote:
> 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
> Please cc Andrea on this.
I'm going to clean up a few small things for a v2 pretty soon, I'll be
sure to cc Andrea there.
> > My proposed solution to the problem is to allow users to set a
> > threshold at which THPs will be handed out. The idea here is that, when
> > a user faults in a page i
> Hm. I think this part is not correct: you collapse temp thp page
> into real one only for current procees. What will happen if a process with
> temp thp pages was forked?
That's a scenario that I hadn't yet addressed, but definitely something
I'll consider going forward. I think we can come up
ocess has THP disabled, and forks off a child, the child
will also have THP disabled. This may not be the desired behavior.
Signed-off-by: Alex Thorlton
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Benjamin Herrenschmidt
Cc: Rik van Riel
Cc: Nao
This just adds a simple check to get khugepaged to behave
appropriately when MMF_THP_DISABLE is set.
Signed-off-by: Alex Thorlton
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Benjamin Herrenschmidt
Cc: Rik van Riel
Cc: Naoya Horiguchi
Cc: Ole
1 - 100 of 251 matches
Mail list logo
