From: Mel Gorman <mgorman@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Andrew Morton <akpm@linux-foundation.org>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
xfs@oss.sgi.com, ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
Date: Tue, 10 Mar 2015 13:08:05 +0000 [thread overview]
Message-ID: <20150310130805.GB3406@suse.de> (raw)
In-Reply-To: <20150309210147.GA3406@suse.de>
On Mon, Mar 09, 2015 at 09:02:19PM +0000, Mel Gorman wrote:
> On Sun, Mar 08, 2015 at 08:40:25PM +0000, Mel Gorman wrote:
> > > Because if the answer is 'yes', then we can safely say: 'we regressed
> > > performance because correctness [not dropping dirty bits] comes before
> > > performance'.
> > >
> > > If the answer is 'no', then we still have a mystery (and a regression)
> > > to track down.
> > >
> > > As a second hack (not to be applied), could we change:
> > >
> > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> > >
> > > to:
> > >
> > > #define _PAGE_BIT_PROTNONE (_PAGE_BIT_GLOBAL+1)
> > >
> >
> > In itself, that's not enough. The SWP_OFFSET_SHIFT would also need updating
> > as a partial revert of 21d9ee3eda7792c45880b2f11bff8e95c9a061fb but it
> > can be done.
> >
>
> More importantily, _PAGE_BIT_GLOBAL+1 == the special PTE bit so just
> updating the value should crash. For the purposes of testing the idea, I
> thought the straight-forward option was to break soft dirty page tracking
> and steal their bit for testing (patch below). Took most of the day to
> get access to the test machine so tests are not long running and only
> the autonuma one has completed;
>
And the xfsrepair workload also does not show any benefit from using a
different bit either
3.19.0 4.0.0-rc1 4.0.0-rc1 4.0.0-rc1
vanilla vanilla slowscan-v2r7 protnone-v3r17
Min real-fsmark 1164.44 ( 0.00%) 1157.41 ( 0.60%) 1150.38 ( 1.21%) 1173.22 ( -0.75%)
Min syst-fsmark 4016.12 ( 0.00%) 3998.06 ( 0.45%) 3988.42 ( 0.69%) 4037.90 ( -0.54%)
Min real-xfsrepair 442.64 ( 0.00%) 497.64 (-12.43%) 456.87 ( -3.21%) 489.60 (-10.61%)
Min syst-xfsrepair 194.97 ( 0.00%) 500.61 (-156.76%) 263.41 (-35.10%) 544.56 (-179.30%)
Amean real-fsmark 1166.28 ( 0.00%) 1166.63 ( -0.03%) 1155.97 ( 0.88%) 1183.19 ( -1.45%)
Amean syst-fsmark 4025.87 ( 0.00%) 4020.94 ( 0.12%) 4004.19 ( 0.54%) 4061.64 ( -0.89%)
Amean real-xfsrepair 447.66 ( 0.00%) 507.85 (-13.45%) 459.58 ( -2.66%) 498.71 (-11.40%)
Amean syst-xfsrepair 202.93 ( 0.00%) 519.88 (-156.19%) 281.63 (-38.78%) 569.21 (-180.50%)
Stddev real-fsmark 1.44 ( 0.00%) 6.55 (-354.10%) 3.97 (-175.65%) 9.20 (-537.90%)
Stddev syst-fsmark 9.76 ( 0.00%) 16.22 (-66.27%) 15.09 (-54.69%) 17.47 (-79.13%)
Stddev real-xfsrepair 5.57 ( 0.00%) 11.17 (-100.68%) 3.41 ( 38.66%) 6.77 (-21.63%)
Stddev syst-xfsrepair 5.69 ( 0.00%) 13.98 (-145.78%) 19.94 (-250.49%) 20.03 (-252.05%)
CoeffVar real-fsmark 0.12 ( 0.00%) 0.56 (-353.96%) 0.34 (-178.11%) 0.78 (-528.79%)
CoeffVar syst-fsmark 0.24 ( 0.00%) 0.40 (-66.48%) 0.38 (-55.53%) 0.43 (-77.55%)
CoeffVar real-xfsrepair 1.24 ( 0.00%) 2.20 (-76.89%) 0.74 ( 40.25%) 1.36 ( -9.17%)
CoeffVar syst-xfsrepair 2.80 ( 0.00%) 2.69 ( 4.06%) 7.08 (-152.54%) 3.52 (-25.51%)
Max real-fsmark 1167.96 ( 0.00%) 1171.98 ( -0.34%) 1159.25 ( 0.75%) 1195.41 ( -2.35%)
Max syst-fsmark 4039.20 ( 0.00%) 4033.84 ( 0.13%) 4024.53 ( 0.36%) 4079.45 ( -1.00%)
Max real-xfsrepair 455.42 ( 0.00%) 523.40 (-14.93%) 464.40 ( -1.97%) 505.82 (-11.07%)
Max syst-xfsrepair 207.94 ( 0.00%) 533.37 (-156.50%) 309.38 (-48.78%) 593.62 (-185.48%)
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Linux-MM <linux-mm@kvack.org>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
Date: Tue, 10 Mar 2015 13:08:05 +0000 [thread overview]
Message-ID: <20150310130805.GB3406@suse.de> (raw)
In-Reply-To: <20150309210147.GA3406@suse.de>
On Mon, Mar 09, 2015 at 09:02:19PM +0000, Mel Gorman wrote:
> On Sun, Mar 08, 2015 at 08:40:25PM +0000, Mel Gorman wrote:
> > > Because if the answer is 'yes', then we can safely say: 'we regressed
> > > performance because correctness [not dropping dirty bits] comes before
> > > performance'.
> > >
> > > If the answer is 'no', then we still have a mystery (and a regression)
> > > to track down.
> > >
> > > As a second hack (not to be applied), could we change:
> > >
> > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> > >
> > > to:
> > >
> > > #define _PAGE_BIT_PROTNONE (_PAGE_BIT_GLOBAL+1)
> > >
> >
> > In itself, that's not enough. The SWP_OFFSET_SHIFT would also need updating
> > as a partial revert of 21d9ee3eda7792c45880b2f11bff8e95c9a061fb but it
> > can be done.
> >
>
> More importantily, _PAGE_BIT_GLOBAL+1 == the special PTE bit so just
> updating the value should crash. For the purposes of testing the idea, I
> thought the straight-forward option was to break soft dirty page tracking
> and steal their bit for testing (patch below). Took most of the day to
> get access to the test machine so tests are not long running and only
> the autonuma one has completed;
>
And the xfsrepair workload also does not show any benefit from using a
different bit either
3.19.0 4.0.0-rc1 4.0.0-rc1 4.0.0-rc1
vanilla vanilla slowscan-v2r7 protnone-v3r17
Min real-fsmark 1164.44 ( 0.00%) 1157.41 ( 0.60%) 1150.38 ( 1.21%) 1173.22 ( -0.75%)
Min syst-fsmark 4016.12 ( 0.00%) 3998.06 ( 0.45%) 3988.42 ( 0.69%) 4037.90 ( -0.54%)
Min real-xfsrepair 442.64 ( 0.00%) 497.64 (-12.43%) 456.87 ( -3.21%) 489.60 (-10.61%)
Min syst-xfsrepair 194.97 ( 0.00%) 500.61 (-156.76%) 263.41 (-35.10%) 544.56 (-179.30%)
Amean real-fsmark 1166.28 ( 0.00%) 1166.63 ( -0.03%) 1155.97 ( 0.88%) 1183.19 ( -1.45%)
Amean syst-fsmark 4025.87 ( 0.00%) 4020.94 ( 0.12%) 4004.19 ( 0.54%) 4061.64 ( -0.89%)
Amean real-xfsrepair 447.66 ( 0.00%) 507.85 (-13.45%) 459.58 ( -2.66%) 498.71 (-11.40%)
Amean syst-xfsrepair 202.93 ( 0.00%) 519.88 (-156.19%) 281.63 (-38.78%) 569.21 (-180.50%)
Stddev real-fsmark 1.44 ( 0.00%) 6.55 (-354.10%) 3.97 (-175.65%) 9.20 (-537.90%)
Stddev syst-fsmark 9.76 ( 0.00%) 16.22 (-66.27%) 15.09 (-54.69%) 17.47 (-79.13%)
Stddev real-xfsrepair 5.57 ( 0.00%) 11.17 (-100.68%) 3.41 ( 38.66%) 6.77 (-21.63%)
Stddev syst-xfsrepair 5.69 ( 0.00%) 13.98 (-145.78%) 19.94 (-250.49%) 20.03 (-252.05%)
CoeffVar real-fsmark 0.12 ( 0.00%) 0.56 (-353.96%) 0.34 (-178.11%) 0.78 (-528.79%)
CoeffVar syst-fsmark 0.24 ( 0.00%) 0.40 (-66.48%) 0.38 (-55.53%) 0.43 (-77.55%)
CoeffVar real-xfsrepair 1.24 ( 0.00%) 2.20 (-76.89%) 0.74 ( 40.25%) 1.36 ( -9.17%)
CoeffVar syst-xfsrepair 2.80 ( 0.00%) 2.69 ( 4.06%) 7.08 (-152.54%) 3.52 (-25.51%)
Max real-fsmark 1167.96 ( 0.00%) 1171.98 ( -0.34%) 1159.25 ( 0.75%) 1195.41 ( -2.35%)
Max syst-fsmark 4039.20 ( 0.00%) 4033.84 ( 0.13%) 4024.53 ( 0.36%) 4079.45 ( -1.00%)
Max real-xfsrepair 455.42 ( 0.00%) 523.40 (-14.93%) 464.40 ( -1.97%) 505.82 (-11.07%)
Max syst-xfsrepair 207.94 ( 0.00%) 533.37 (-156.50%) 309.38 (-48.78%) 593.62 (-185.48%)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Andrew Morton <akpm@linux-foundation.org>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
xfs@oss.sgi.com, ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
Date: Tue, 10 Mar 2015 13:08:05 +0000 [thread overview]
Message-ID: <20150310130805.GB3406@suse.de> (raw)
In-Reply-To: <20150309210147.GA3406@suse.de>
On Mon, Mar 09, 2015 at 09:02:19PM +0000, Mel Gorman wrote:
> On Sun, Mar 08, 2015 at 08:40:25PM +0000, Mel Gorman wrote:
> > > Because if the answer is 'yes', then we can safely say: 'we regressed
> > > performance because correctness [not dropping dirty bits] comes before
> > > performance'.
> > >
> > > If the answer is 'no', then we still have a mystery (and a regression)
> > > to track down.
> > >
> > > As a second hack (not to be applied), could we change:
> > >
> > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> > >
> > > to:
> > >
> > > #define _PAGE_BIT_PROTNONE (_PAGE_BIT_GLOBAL+1)
> > >
> >
> > In itself, that's not enough. The SWP_OFFSET_SHIFT would also need updating
> > as a partial revert of 21d9ee3eda7792c45880b2f11bff8e95c9a061fb but it
> > can be done.
> >
>
> More importantily, _PAGE_BIT_GLOBAL+1 == the special PTE bit so just
> updating the value should crash. For the purposes of testing the idea, I
> thought the straight-forward option was to break soft dirty page tracking
> and steal their bit for testing (patch below). Took most of the day to
> get access to the test machine so tests are not long running and only
> the autonuma one has completed;
>
And the xfsrepair workload also does not show any benefit from using a
different bit either
3.19.0 4.0.0-rc1 4.0.0-rc1 4.0.0-rc1
vanilla vanilla slowscan-v2r7 protnone-v3r17
Min real-fsmark 1164.44 ( 0.00%) 1157.41 ( 0.60%) 1150.38 ( 1.21%) 1173.22 ( -0.75%)
Min syst-fsmark 4016.12 ( 0.00%) 3998.06 ( 0.45%) 3988.42 ( 0.69%) 4037.90 ( -0.54%)
Min real-xfsrepair 442.64 ( 0.00%) 497.64 (-12.43%) 456.87 ( -3.21%) 489.60 (-10.61%)
Min syst-xfsrepair 194.97 ( 0.00%) 500.61 (-156.76%) 263.41 (-35.10%) 544.56 (-179.30%)
Amean real-fsmark 1166.28 ( 0.00%) 1166.63 ( -0.03%) 1155.97 ( 0.88%) 1183.19 ( -1.45%)
Amean syst-fsmark 4025.87 ( 0.00%) 4020.94 ( 0.12%) 4004.19 ( 0.54%) 4061.64 ( -0.89%)
Amean real-xfsrepair 447.66 ( 0.00%) 507.85 (-13.45%) 459.58 ( -2.66%) 498.71 (-11.40%)
Amean syst-xfsrepair 202.93 ( 0.00%) 519.88 (-156.19%) 281.63 (-38.78%) 569.21 (-180.50%)
Stddev real-fsmark 1.44 ( 0.00%) 6.55 (-354.10%) 3.97 (-175.65%) 9.20 (-537.90%)
Stddev syst-fsmark 9.76 ( 0.00%) 16.22 (-66.27%) 15.09 (-54.69%) 17.47 (-79.13%)
Stddev real-xfsrepair 5.57 ( 0.00%) 11.17 (-100.68%) 3.41 ( 38.66%) 6.77 (-21.63%)
Stddev syst-xfsrepair 5.69 ( 0.00%) 13.98 (-145.78%) 19.94 (-250.49%) 20.03 (-252.05%)
CoeffVar real-fsmark 0.12 ( 0.00%) 0.56 (-353.96%) 0.34 (-178.11%) 0.78 (-528.79%)
CoeffVar syst-fsmark 0.24 ( 0.00%) 0.40 (-66.48%) 0.38 (-55.53%) 0.43 (-77.55%)
CoeffVar real-xfsrepair 1.24 ( 0.00%) 2.20 (-76.89%) 0.74 ( 40.25%) 1.36 ( -9.17%)
CoeffVar syst-xfsrepair 2.80 ( 0.00%) 2.69 ( 4.06%) 7.08 (-152.54%) 3.52 (-25.51%)
Max real-fsmark 1167.96 ( 0.00%) 1171.98 ( -0.34%) 1159.25 ( 0.75%) 1195.41 ( -2.35%)
Max syst-fsmark 4039.20 ( 0.00%) 4033.84 ( 0.13%) 4024.53 ( 0.36%) 4079.45 ( -1.00%)
Max real-xfsrepair 455.42 ( 0.00%) 523.40 (-14.93%) 464.40 ( -1.97%) 505.82 (-11.07%)
Max syst-xfsrepair 207.94 ( 0.00%) 533.37 (-156.50%) 309.38 (-48.78%) 593.62 (-185.48%)
--
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: Mel Gorman <mgorman@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>,
Dave Chinner <david@fromorbit.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Linux-MM <linux-mm@kvack.org>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
Date: Tue, 10 Mar 2015 13:08:05 +0000 [thread overview]
Message-ID: <20150310130805.GB3406@suse.de> (raw)
In-Reply-To: <20150309210147.GA3406@suse.de>
On Mon, Mar 09, 2015 at 09:02:19PM +0000, Mel Gorman wrote:
> On Sun, Mar 08, 2015 at 08:40:25PM +0000, Mel Gorman wrote:
> > > Because if the answer is 'yes', then we can safely say: 'we regressed
> > > performance because correctness [not dropping dirty bits] comes before
> > > performance'.
> > >
> > > If the answer is 'no', then we still have a mystery (and a regression)
> > > to track down.
> > >
> > > As a second hack (not to be applied), could we change:
> > >
> > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> > >
> > > to:
> > >
> > > #define _PAGE_BIT_PROTNONE (_PAGE_BIT_GLOBAL+1)
> > >
> >
> > In itself, that's not enough. The SWP_OFFSET_SHIFT would also need updating
> > as a partial revert of 21d9ee3eda7792c45880b2f11bff8e95c9a061fb but it
> > can be done.
> >
>
> More importantily, _PAGE_BIT_GLOBAL+1 == the special PTE bit so just
> updating the value should crash. For the purposes of testing the idea, I
> thought the straight-forward option was to break soft dirty page tracking
> and steal their bit for testing (patch below). Took most of the day to
> get access to the test machine so tests are not long running and only
> the autonuma one has completed;
>
And the xfsrepair workload also does not show any benefit from using a
different bit either
3.19.0 4.0.0-rc1 4.0.0-rc1 4.0.0-rc1
vanilla vanilla slowscan-v2r7 protnone-v3r17
Min real-fsmark 1164.44 ( 0.00%) 1157.41 ( 0.60%) 1150.38 ( 1.21%) 1173.22 ( -0.75%)
Min syst-fsmark 4016.12 ( 0.00%) 3998.06 ( 0.45%) 3988.42 ( 0.69%) 4037.90 ( -0.54%)
Min real-xfsrepair 442.64 ( 0.00%) 497.64 (-12.43%) 456.87 ( -3.21%) 489.60 (-10.61%)
Min syst-xfsrepair 194.97 ( 0.00%) 500.61 (-156.76%) 263.41 (-35.10%) 544.56 (-179.30%)
Amean real-fsmark 1166.28 ( 0.00%) 1166.63 ( -0.03%) 1155.97 ( 0.88%) 1183.19 ( -1.45%)
Amean syst-fsmark 4025.87 ( 0.00%) 4020.94 ( 0.12%) 4004.19 ( 0.54%) 4061.64 ( -0.89%)
Amean real-xfsrepair 447.66 ( 0.00%) 507.85 (-13.45%) 459.58 ( -2.66%) 498.71 (-11.40%)
Amean syst-xfsrepair 202.93 ( 0.00%) 519.88 (-156.19%) 281.63 (-38.78%) 569.21 (-180.50%)
Stddev real-fsmark 1.44 ( 0.00%) 6.55 (-354.10%) 3.97 (-175.65%) 9.20 (-537.90%)
Stddev syst-fsmark 9.76 ( 0.00%) 16.22 (-66.27%) 15.09 (-54.69%) 17.47 (-79.13%)
Stddev real-xfsrepair 5.57 ( 0.00%) 11.17 (-100.68%) 3.41 ( 38.66%) 6.77 (-21.63%)
Stddev syst-xfsrepair 5.69 ( 0.00%) 13.98 (-145.78%) 19.94 (-250.49%) 20.03 (-252.05%)
CoeffVar real-fsmark 0.12 ( 0.00%) 0.56 (-353.96%) 0.34 (-178.11%) 0.78 (-528.79%)
CoeffVar syst-fsmark 0.24 ( 0.00%) 0.40 (-66.48%) 0.38 (-55.53%) 0.43 (-77.55%)
CoeffVar real-xfsrepair 1.24 ( 0.00%) 2.20 (-76.89%) 0.74 ( 40.25%) 1.36 ( -9.17%)
CoeffVar syst-xfsrepair 2.80 ( 0.00%) 2.69 ( 4.06%) 7.08 (-152.54%) 3.52 (-25.51%)
Max real-fsmark 1167.96 ( 0.00%) 1171.98 ( -0.34%) 1159.25 ( 0.75%) 1195.41 ( -2.35%)
Max syst-fsmark 4039.20 ( 0.00%) 4033.84 ( 0.13%) 4024.53 ( 0.36%) 4079.45 ( -1.00%)
Max real-xfsrepair 455.42 ( 0.00%) 523.40 (-14.93%) 464.40 ( -1.97%) 505.82 (-11.07%)
Max syst-xfsrepair 207.94 ( 0.00%) 533.37 (-156.50%) 309.38 (-48.78%) 593.62 (-185.48%)
next prev parent reply other threads:[~2015-03-10 13:08 UTC|newest]
Thread overview: 195+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 15:20 [RFC PATCH 0/4] Automatic NUMA balancing and PROT_NONE handling followup v2r8 Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` [PATCH 1/4] mm: thp: Return the correct value for change_huge_pmd Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 20:13 ` Linus Torvalds
2015-03-07 20:13 ` Linus Torvalds
2015-03-07 20:13 ` Linus Torvalds
2015-03-07 20:13 ` Linus Torvalds
2015-03-07 20:31 ` Linus Torvalds
2015-03-07 20:31 ` Linus Torvalds
2015-03-07 20:31 ` Linus Torvalds
2015-03-07 20:31 ` Linus Torvalds
2015-03-07 20:56 ` Mel Gorman
2015-03-07 20:56 ` Mel Gorman
2015-03-07 20:56 ` Mel Gorman
2015-03-07 20:56 ` Mel Gorman
2015-03-07 15:20 ` [PATCH 2/4] mm: numa: Remove migrate_ratelimited Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` [PATCH 3/4] mm: numa: Mark huge PTEs young when clearing NUMA hinting faults Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 18:33 ` Linus Torvalds
2015-03-07 18:33 ` Linus Torvalds
2015-03-07 18:33 ` Linus Torvalds
2015-03-07 18:33 ` Linus Torvalds
2015-03-07 18:42 ` Linus Torvalds
2015-03-07 18:42 ` Linus Torvalds
2015-03-07 18:42 ` Linus Torvalds
2015-03-07 18:42 ` Linus Torvalds
2015-03-07 15:20 ` [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 15:20 ` Mel Gorman
2015-03-07 16:36 ` Ingo Molnar
2015-03-07 16:36 ` Ingo Molnar
2015-03-07 16:36 ` Ingo Molnar
2015-03-07 16:36 ` Ingo Molnar
2015-03-07 17:37 ` Mel Gorman
2015-03-07 17:37 ` Mel Gorman
2015-03-07 17:37 ` Mel Gorman
2015-03-07 17:37 ` Mel Gorman
2015-03-08 9:54 ` Ingo Molnar
2015-03-08 9:54 ` Ingo Molnar
2015-03-08 9:54 ` Ingo Molnar
2015-03-08 9:54 ` Ingo Molnar
2015-03-07 19:12 ` Linus Torvalds
2015-03-07 19:12 ` Linus Torvalds
2015-03-07 19:12 ` Linus Torvalds
2015-03-07 19:12 ` Linus Torvalds
2015-03-08 10:02 ` Ingo Molnar
2015-03-08 10:02 ` Ingo Molnar
2015-03-08 10:02 ` Ingo Molnar
2015-03-08 10:02 ` Ingo Molnar
2015-03-08 18:35 ` Linus Torvalds
2015-03-08 18:35 ` Linus Torvalds
2015-03-08 18:35 ` Linus Torvalds
2015-03-08 18:35 ` Linus Torvalds
2015-03-08 18:46 ` Linus Torvalds
2015-03-08 18:46 ` Linus Torvalds
2015-03-08 18:46 ` Linus Torvalds
2015-03-08 18:46 ` Linus Torvalds
2015-03-09 11:29 ` Dave Chinner
2015-03-09 11:29 ` Dave Chinner
2015-03-09 11:29 ` Dave Chinner
2015-03-09 11:29 ` Dave Chinner
2015-03-09 16:52 ` Linus Torvalds
2015-03-09 16:52 ` Linus Torvalds
2015-03-09 16:52 ` Linus Torvalds
2015-03-09 16:52 ` Linus Torvalds
2015-03-09 19:19 ` Dave Chinner
2015-03-09 19:19 ` Dave Chinner
2015-03-09 19:19 ` Dave Chinner
2015-03-10 23:55 ` Linus Torvalds
2015-03-10 23:55 ` Linus Torvalds
2015-03-10 23:55 ` Linus Torvalds
2015-03-10 23:55 ` Linus Torvalds
2015-03-12 13:10 ` Mel Gorman
2015-03-12 13:10 ` Mel Gorman
2015-03-12 13:10 ` Mel Gorman
2015-03-12 13:10 ` Mel Gorman
2015-03-12 16:20 ` Linus Torvalds
2015-03-12 16:20 ` Linus Torvalds
2015-03-12 16:20 ` Linus Torvalds
2015-03-12 16:20 ` Linus Torvalds
2015-03-12 18:49 ` Mel Gorman
2015-03-12 18:49 ` Mel Gorman
2015-03-12 18:49 ` Mel Gorman
2015-03-12 18:49 ` Mel Gorman
2015-03-17 7:06 ` Dave Chinner
2015-03-17 7:06 ` Dave Chinner
2015-03-17 7:06 ` Dave Chinner
2015-03-17 7:06 ` Dave Chinner
2015-03-17 16:53 ` Linus Torvalds
2015-03-17 16:53 ` Linus Torvalds
2015-03-17 16:53 ` Linus Torvalds
2015-03-17 16:53 ` Linus Torvalds
2015-03-17 20:51 ` Dave Chinner
2015-03-17 20:51 ` Dave Chinner
2015-03-17 20:51 ` Dave Chinner
2015-03-17 20:51 ` Dave Chinner
2015-03-17 21:30 ` Linus Torvalds
2015-03-17 21:30 ` Linus Torvalds
2015-03-17 21:30 ` Linus Torvalds
2015-03-17 21:30 ` Linus Torvalds
2015-03-17 22:08 ` Dave Chinner
2015-03-17 22:08 ` Dave Chinner
2015-03-17 22:08 ` Dave Chinner
2015-03-17 22:08 ` Dave Chinner
2015-03-18 16:08 ` Linus Torvalds
2015-03-18 16:08 ` Linus Torvalds
2015-03-18 16:08 ` Linus Torvalds
2015-03-18 16:08 ` Linus Torvalds
2015-03-18 17:31 ` Linus Torvalds
2015-03-18 17:31 ` Linus Torvalds
2015-03-18 17:31 ` Linus Torvalds
2015-03-18 17:31 ` Linus Torvalds
2015-03-18 22:23 ` Dave Chinner
2015-03-18 22:23 ` Dave Chinner
2015-03-18 22:23 ` Dave Chinner
2015-03-18 22:23 ` Dave Chinner
2015-03-19 14:10 ` Mel Gorman
2015-03-19 14:10 ` Mel Gorman
2015-03-19 14:10 ` Mel Gorman
2015-03-19 14:10 ` Mel Gorman
2015-03-19 18:09 ` Linus Torvalds
2015-03-19 18:09 ` Linus Torvalds
2015-03-19 18:09 ` Linus Torvalds
2015-03-19 18:09 ` Linus Torvalds
2015-03-19 21:41 ` Linus Torvalds
2015-03-19 21:41 ` Linus Torvalds
2015-03-19 21:41 ` Linus Torvalds
2015-03-19 21:41 ` Linus Torvalds
2015-03-19 22:41 ` Dave Chinner
2015-03-19 22:41 ` Dave Chinner
2015-03-19 22:41 ` Dave Chinner
2015-03-19 22:41 ` Dave Chinner
2015-03-19 23:05 ` Linus Torvalds
2015-03-19 23:05 ` Linus Torvalds
2015-03-19 23:05 ` Linus Torvalds
2015-03-19 23:05 ` Linus Torvalds
2015-03-19 23:23 ` Dave Chinner
2015-03-19 23:23 ` Dave Chinner
2015-03-19 23:23 ` Dave Chinner
2015-03-19 23:23 ` Dave Chinner
2015-03-20 0:23 ` Dave Chinner
2015-03-20 0:23 ` Dave Chinner
2015-03-20 0:23 ` Dave Chinner
2015-03-20 0:23 ` Dave Chinner
2015-03-20 1:29 ` Linus Torvalds
2015-03-20 1:29 ` Linus Torvalds
2015-03-20 1:29 ` Linus Torvalds
2015-03-20 1:29 ` Linus Torvalds
2015-03-20 4:13 ` Dave Chinner
2015-03-20 4:13 ` Dave Chinner
2015-03-20 4:13 ` Dave Chinner
2015-03-20 4:13 ` Dave Chinner
2015-03-20 17:02 ` Linus Torvalds
2015-03-20 17:02 ` Linus Torvalds
2015-03-20 17:02 ` Linus Torvalds
2015-03-20 17:02 ` Linus Torvalds
2015-03-23 12:01 ` Mel Gorman
2015-03-23 12:01 ` Mel Gorman
2015-03-23 12:01 ` Mel Gorman
2015-03-23 12:01 ` Mel Gorman
2015-03-20 10:12 ` Mel Gorman
2015-03-20 10:12 ` Mel Gorman
2015-03-20 10:12 ` Mel Gorman
2015-03-20 10:12 ` Mel Gorman
2015-03-20 9:56 ` Mel Gorman
2015-03-20 9:56 ` Mel Gorman
2015-03-20 9:56 ` Mel Gorman
2015-03-20 9:56 ` Mel Gorman
2015-03-08 20:40 ` Mel Gorman
2015-03-08 20:40 ` Mel Gorman
2015-03-08 20:40 ` Mel Gorman
2015-03-08 20:40 ` Mel Gorman
2015-03-09 21:02 ` Mel Gorman
2015-03-09 21:02 ` Mel Gorman
2015-03-09 21:02 ` Mel Gorman
2015-03-09 21:02 ` Mel Gorman
2015-03-10 13:08 ` Mel Gorman [this message]
2015-03-10 13:08 ` Mel Gorman
2015-03-10 13:08 ` Mel Gorman
2015-03-10 13:08 ` Mel Gorman
2015-03-08 9:41 ` Ingo Molnar
2015-03-08 9:41 ` Ingo Molnar
2015-03-08 9:41 ` Ingo Molnar
2015-03-08 9:41 ` Ingo Molnar
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=20150310130805.GB3406@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=xfs@oss.sgi.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.