consequences as it changes the behaviour for the entire
lifetime of the workload. It could cause excessive migrations in the case
where a machine is almost fully utilised and getting load balanced or in
cases where tasks are pulled frequently cross-node (e.g. worker thread
model or a pipelined computation).
I'm only looking to address the case where the load balancer spreads a
workload early and the memory should move to the new node quickly. If it
turns out there are cases where that decision is wrong, it gets remedied
quickly but if your proposal is ever wrong, the system doesn't recover.
--
Mel Gorman
SUSE Labs
consequences as it changes the behaviour for the entire
lifetime of the workload. It could cause excessive migrations in the case
where a machine is almost fully utilised and getting load balanced or in
cases where tasks are pulled frequently cross-node (e.g. worker thread
model or a pipelined computation).
I'm only looking to address the case where the load balancer spreads a
workload early and the memory should move to the new node quickly. If it
turns out there are cases where that decision is wrong, it gets remedied
quickly but if your proposal is ever wrong, the system doesn't recover.
--
Mel Gorman
SUSE Labs
nt check we end up spreading memory faster
> than we should hence hurting the chance of early consolidation.
>
> Can we restrict to something like this?
>
> if (p->numa_scan_seq >=MIN && p->numa_scan_seq <= MIN+4 &&
> (cpupid_match_pid(p, last_cpupid)))
>
nt check we end up spreading memory faster
> than we should hence hurting the chance of early consolidation.
>
> Can we restrict to something like this?
>
> if (p->numa_scan_seq >=MIN && p->numa_scan_seq <= MIN+4 &&
> (cpupid_match_pid(p, last_cpupid)))
>
Commit-ID: 37355bdc5a129899f6b245900a8eb944a092f7fd
Gitweb: https://git.kernel.org/tip/37355bdc5a129899f6b245900a8eb944a092f7fd
Author: Mel Gorman
AuthorDate: Mon, 1 Oct 2018 11:05:25 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 11:31:33 +0200
sched/numa: Migrate pages
Commit-ID: 37355bdc5a129899f6b245900a8eb944a092f7fd
Gitweb: https://git.kernel.org/tip/37355bdc5a129899f6b245900a8eb944a092f7fd
Author: Mel Gorman
AuthorDate: Mon, 1 Oct 2018 11:05:25 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 11:31:33 +0200
sched/numa: Migrate pages
Commit-ID: efaffc5e40aeced0bcb497ed7a0a5b8c14abfcdf
Gitweb: https://git.kernel.org/tip/efaffc5e40aeced0bcb497ed7a0a5b8c14abfcdf
Author: Mel Gorman
AuthorDate: Mon, 1 Oct 2018 11:05:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 11:31:14 +0200
mm, sched/numa: Remove rate
Commit-ID: efaffc5e40aeced0bcb497ed7a0a5b8c14abfcdf
Gitweb: https://git.kernel.org/tip/efaffc5e40aeced0bcb497ed7a0a5b8c14abfcdf
Author: Mel Gorman
AuthorDate: Mon, 1 Oct 2018 11:05:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 11:31:14 +0200
mm, sched/numa: Remove rate
Commit-ID: 05cbdf4f5c191ff378c47bbf66d7230beb725bdb
Gitweb: https://git.kernel.org/tip/05cbdf4f5c191ff378c47bbf66d7230beb725bdb
Author: Mel Gorman
AuthorDate: Fri, 21 Sep 2018 23:18:59 +0530
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 09:42:24 +0200
sched/numa: Limit
Commit-ID: 05cbdf4f5c191ff378c47bbf66d7230beb725bdb
Gitweb: https://git.kernel.org/tip/05cbdf4f5c191ff378c47bbf66d7230beb725bdb
Author: Mel Gorman
AuthorDate: Fri, 21 Sep 2018 23:18:59 +0530
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 09:42:24 +0200
sched/numa: Limit
These two patches are based on top of Srikar Dronamraju's recent work
on automatic NUMA balancing and are motivated by a bug report from Jirka
Hladky that STREAM performance has regressed.
The STREAM workload is mildly interesting in that it only works as a valid
benchmark if tasks are pinned to
( 9.32%)47219.24 (
9.06%)
MB/sec scale30115.06 ( 0.00%)32568.12 ( 8.15%)32527.56 (
8.01%)
MB/sec add 32825.12 ( 0.00%)36078.94 ( 9.91%)35928.02 (
9.45%)
MB/sec triad32549.52 ( 0.00%)35935.94 ( 10.40%)35969.88 (
10.51%)
Signed-off-by: Mel
These two patches are based on top of Srikar Dronamraju's recent work
on automatic NUMA balancing and are motivated by a bug report from Jirka
Hladky that STREAM performance has regressed.
The STREAM workload is mildly interesting in that it only works as a valid
benchmark if tasks are pinned to
( 9.32%)47219.24 (
9.06%)
MB/sec scale30115.06 ( 0.00%)32568.12 ( 8.15%)32527.56 (
8.01%)
MB/sec add 32825.12 ( 0.00%)36078.94 ( 9.91%)35928.02 (
9.45%)
MB/sec triad32549.52 ( 0.00%)35935.94 ( 10.40%)35969.88 (
10.51%)
Signed-off-by: Mel
noratelimit-v1r1
MB/sec copy 43298.52 ( 0.00%)44673.38 ( 3.18%)
MB/sec scale30115.06 ( 0.00%)31293.06 ( 3.91%)
MB/sec add 32825.12 ( 0.00%)34883.62 ( 6.27%)
MB/sec triad32549.52 ( 0.00%)34906.60 ( 7.24%
Signed-off-by: Mel Gorman
---
include
noratelimit-v1r1
MB/sec copy 43298.52 ( 0.00%)44673.38 ( 3.18%)
MB/sec scale30115.06 ( 0.00%)31293.06 ( 3.91%)
MB/sec add 32825.12 ( 0.00%)34883.62 ( 6.27%)
MB/sec triad32549.52 ( 0.00%)34906.60 ( 7.24%
Signed-off-by: Mel Gorman
---
include
e concepts were generally covered by academic textbooks AFAIK.
--
Mel Gorman
SUSE Labs
e concepts were generally covered by academic textbooks AFAIK.
--
Mel Gorman
SUSE Labs
hich allows for the node reclaim like behavior
> for the specific memory ranges which would allow a
>
> [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarca...@redhat.com
>
> [mho...@suse.com: rewrote the changelog based on the one from Andrea]
> Fixes: 5265047ac301 ("mm,
hich allows for the node reclaim like behavior
> for the specific memory ranges which would allow a
>
> [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarca...@redhat.com
>
> [mho...@suse.com: rewrote the changelog based on the one from Andrea]
> Fixes: 5265047ac301 ("mm,
On Fri, Sep 14, 2018 at 04:50:20PM +0200, Jirka Hladky wrote:
> Hi Peter and Srikar,
>
> > I have bounced the 5 patches to you, (one of the 6 has not been applied by
> > Peter) so I have skipped that.
> > They can also be fetched from
> >
On Fri, Sep 14, 2018 at 04:50:20PM +0200, Jirka Hladky wrote:
> Hi Peter and Srikar,
>
> > I have bounced the 5 patches to you, (one of the 6 has not been applied by
> > Peter) so I have skipped that.
> > They can also be fetched from
> >
On Wed, Sep 12, 2018 at 11:57:42AM +0200, Ingo Molnar wrote:
> > * Mel Gorman [2018-09-10 10:41:47]:
> >
> > > On Fri, Sep 07, 2018 at 01:37:39PM +0100, Mel Gorman wrote:
> > > > > Srikar's patch here:
> > > > >
> > > > >
&g
On Wed, Sep 12, 2018 at 11:57:42AM +0200, Ingo Molnar wrote:
> > * Mel Gorman [2018-09-10 10:41:47]:
> >
> > > On Fri, Sep 07, 2018 at 01:37:39PM +0100, Mel Gorman wrote:
> > > > > Srikar's patch here:
> > > > >
> > > > >
&g
I had were marginal which is why I was not convinced the
complexity was justified.
Your ppc64 figures look a bit more convincing and while I'm disappointed
that you did not make a like-like comparison, I'm happy enough to go with
your version. I can re-evaluate "Stop comparing tasks for NUMA placement"
on its own later as well as the fast-migrate patches.
Thanks Srikar.
--
Mel Gorman
SUSE Labs
I had were marginal which is why I was not convinced the
complexity was justified.
Your ppc64 figures look a bit more convincing and while I'm disappointed
that you did not make a like-like comparison, I'm happy enough to go with
your version. I can re-evaluate "Stop comparing tasks for NUMA placement"
on its own later as well as the fast-migrate patches.
Thanks Srikar.
--
Mel Gorman
SUSE Labs
On Fri, Sep 07, 2018 at 01:37:39PM +0100, Mel Gorman wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index d59d3e00a480..d4c289c11012 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -1560,7 +1
On Fri, Sep 07, 2018 at 01:37:39PM +0100, Mel Gorman wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index d59d3e00a480..d4c289c11012 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -1560,7 +1
.
>
There is a chance but to find out, the task has to be dequeued and requeued
on a maybe. An idle CPU is less disruptive and the only task affected is
migrating to the preferred node where, based on previous fault behaviour,
should have better locality. It's also a simplier patch but I'm going to
be biased towards my own patch, the tests will decide one way or the other.
--
Mel Gorman
SUSE Labs
.
>
There is a chance but to find out, the task has to be dequeued and requeued
on a maybe. An idle CPU is less disruptive and the only task affected is
migrating to the preferred node where, based on previous fault behaviour,
should have better locality. It's also a simplier patch but I'm going to
be biased towards my own patch, the tests will decide one way or the other.
--
Mel Gorman
SUSE Labs
On Fri, Sep 07, 2018 at 06:35:53PM +0530, Srikar Dronamraju wrote:
> * Mel Gorman [2018-09-07 11:11:38]:
>
> > task_numa_migrate is responsible for finding a core on a preferred NUMA
> > node for a task. As part of this, task_numa_find_cpu iterates through
> > the CPUs
On Fri, Sep 07, 2018 at 06:35:53PM +0530, Srikar Dronamraju wrote:
> * Mel Gorman [2018-09-07 11:11:38]:
>
> > task_numa_migrate is responsible for finding a core on a preferred NUMA
> > node for a task. As part of this, task_numa_find_cpu iterates through
> > the CPUs
>
> Also frobs this condition, but in a less radical way. Does that yield
> similar results?
I can check. I do wonder of course if the less radical approach just means
that automatic NUMA balancing and the load balancer simply disagree about
placement at a different time. It'll take a few days to have an answer as
the battery of workloads to check this take ages.
--
Mel Gorman
SUSE Labs
>
> Also frobs this condition, but in a less radical way. Does that yield
> similar results?
I can check. I do wonder of course if the less radical approach just means
that automatic NUMA balancing and the load balancer simply disagree about
placement at a different time. It'll take a few days to have an answer as
the battery of workloads to check this take ages.
--
Mel Gorman
SUSE Labs
On Fri, Sep 07, 2018 at 01:24:55PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 07, 2018 at 11:11:35AM +0100, Mel Gorman wrote:
> > Srikar had an automatic NUMA balancing series merged during the 4.19 window
> > and there some issues I missed during review that this s
On Fri, Sep 07, 2018 at 01:24:55PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 07, 2018 at 11:11:35AM +0100, Mel Gorman wrote:
> > Srikar had an automatic NUMA balancing series merged during the 4.19 window
> > and there some issues I missed during review that this s
Srikar had an automatic NUMA balancing series merged during the 4.19 window
and there some issues I missed during review that this series addresses.
Patches 1-2 are simply removing redundant code and calculations that are
never used.
Patch 3 makes the observation that we can call
Srikar had an automatic NUMA balancing series merged during the 4.19 window
and there some issues I missed during review that this series addresses.
Patches 1-2 are simply removing redundant code and calculations that are
never used.
Patch 3 makes the observation that we can call
The nr_running field has not been used since commit 2d4056fafa19
("sched/numa: Remove numa_has_capacity()") so remove it.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b3
The nr_running field has not been used since commit 2d4056fafa19
("sched/numa: Remove numa_has_capacity()") so remove it.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b3
Commit 2d4056fafa19 ("sched/numa: Remove numa_has_capacity()") removed
the the has_free_capacity field but did not remove calculations
related to it in update_numa_stats. This patch removes the unused
code.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 22 +---
Commit 2d4056fafa19 ("sched/numa: Remove numa_has_capacity()") removed
the the has_free_capacity field but did not remove calculations
related to it in update_numa_stats. This patch removes the unused
code.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 22 +---
migrations
552,529 page-faults
26 sched:sched_move_numa
0 sched:sched_stick_numa
16 sched:sched_swap_numa
Note the large drop in CPU migrations, the calls to sched_move_numa and
page faults.
Signed-off-by: Mel Gorman
---
ke
-utilised.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5b2f1684e96e..d59d3e00a480 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1535,7 +1535,7
migrations
552,529 page-faults
26 sched:sched_move_numa
0 sched:sched_stick_numa
16 sched:sched_swap_numa
Note the large drop in CPU migrations, the calls to sched_move_numa and
page faults.
Signed-off-by: Mel Gorman
---
ke
-utilised.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5b2f1684e96e..d59d3e00a480 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1535,7 +1535,7
would also end up with a much more sensible cc
list.
--
Mel Gorman
SUSE Labs
would also end up with a much more sensible cc
list.
--
Mel Gorman
SUSE Labs
056fafa196e1ab4e7161bae4df76f9602d56d is the source of the
issue as at least one auto-bisection found that it may be problematic.
Whether it is an issue or not depends heavily on the number of threads
relative to a socket size.
--
Mel Gorman
SUSE Labs
056fafa196e1ab4e7161bae4df76f9602d56d is the source of the
issue as at least one auto-bisection found that it may be problematic.
Whether it is an issue or not depends heavily on the number of threads
relative to a socket size.
--
Mel Gorman
SUSE Labs
So
> even GFP_ATOMIC would now ignore mempolicies after the initial attempts
> fail - if the code worked as people thought it does.
>
> Link: http://lkml.kernel.org/r/20180612122624.8045-1-vba...@suse.cz
> Signed-off-by: Vlastimil Babka
> Cc: Mel Gorman
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Signed-off-by: Andrew Morton
FWIW, I thought I acked this already.
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
So
> even GFP_ATOMIC would now ignore mempolicies after the initial attempts
> fail - if the code worked as people thought it does.
>
> Link: http://lkml.kernel.org/r/20180612122624.8045-1-vba...@suse.cz
> Signed-off-by: Vlastimil Babka
> Cc: Mel Gorman
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Signed-off-by: Andrew Morton
FWIW, I thought I acked this already.
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
top.org/show_bug.cgi?id=107410
> Reported-by: Eero Tamminen
> Signed-off-by: Srinivas Pandruvada
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
top.org/show_bug.cgi?id=107410
> Reported-by: Eero Tamminen
> Signed-off-by: Srinivas Pandruvada
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
rutilize it).
Dbench for example can be quite CPU intensive. When bound to a single
core, it shows up to 80% utilisation of a single core. When unbound,
the usage of individual cores appears low due to the migrations. It may
be intermittent usage as it context switches to worker threads but it's
not lo
rutilize it).
Dbench for example can be quite CPU intensive. When bound to a single
core, it shows up to 80% utilisation of a single core. When unbound,
the usage of individual cores appears low due to the migrations. It may
be intermittent usage as it context switches to worker threads but it's
not lo
ard needs the power
and not the CPU, a straight revert is not the answer. Without the series,
HWP cripplies the CPU.
--
Mel Gorman
SUSE Labs
ard needs the power
and not the CPU, a straight revert is not the answer. Without the series,
HWP cripplies the CPU.
--
Mel Gorman
SUSE Labs
ntation stats for slab/slub if they are particularly
stupid parsers but other than that;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
ntation stats for slab/slub if they are particularly
stupid parsers but other than that;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
idered in MemAvailable calculation and
> overcommit decisions.
>
> Signed-off-by: Vlastimil Babka
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
idered in MemAvailable calculation and
> overcommit decisions.
>
> Signed-off-by: Vlastimil Babka
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
freelist. Functionally the
patch appears to be fine.
--
Mel Gorman
SUSE Labs
freelist. Functionally the
patch appears to be fine.
--
Mel Gorman
SUSE Labs
; + if (!kmalloc_caches[type][i])
> + new_kmalloc_cache(i, type, flags);
>
I don't see a problem here as such but the values of the KMALLOC_* types
is important both for this function and the kmalloc_type(). It might be
worth adding a warning that these functions be examined if updating the
types but then again, anyone trying and getting it wrong will have a
broken kernel so;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
; + if (!kmalloc_caches[type][i])
> + new_kmalloc_cache(i, type, flags);
>
I don't see a problem here as such but the values of the KMALLOC_* types
is important both for this function and the kmalloc_type(). It might be
worth adding a warning that these functions be examined if updating the
types but then again, anyone trying and getting it wrong will have a
broken kernel so;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
require the DMA zone.
Some of them are certainly bogus such as in drivers for archs that only
have one zone and is probably a reflection of the confusing naming. The
audit would be a mess and unrelated to the patch so for this patch;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
require the DMA zone.
Some of them are certainly bogus such as in drivers for archs that only
have one zone and is probably a reflection of the confusing naming. The
audit would be a mess and unrelated to the patch so for this patch;
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
s updated.
> Thanks a lot for your efforts to improve the performance!
My pleasure.
--
Mel Gorman
SUSE Labs
s updated.
> Thanks a lot for your efforts to improve the performance!
My pleasure.
--
Mel Gorman
SUSE Labs
9f922b095f4ec94d581c3.
> ---
> mm/memory.c | 14 +---------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
9f922b095f4ec94d581c3.
> ---
> mm/memory.c | 14 +---------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
c.c
+++ b/mm/page_alloc.c
@@ -6211,11 +6211,6 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat)
int nid = pgdat->node_id;
pgdat_resize_init(pgdat);
-#ifdef CONFIG_NUMA_BALANCING
- pgdat->numabalancing_migrate_nr_pages = 0;
- pgdat->active_node_migrate = 0;
- pgdat->numabalancing_migrate_next_window = jiffies;
-#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
spin_lock_init(>split_queue_lock);
INIT_LIST_HEAD(>split_queue);
--
Mel Gorman
SUSE Labs
c.c
+++ b/mm/page_alloc.c
@@ -6211,11 +6211,6 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat)
int nid = pgdat->node_id;
pgdat_resize_init(pgdat);
-#ifdef CONFIG_NUMA_BALANCING
- pgdat->numabalancing_migrate_nr_pages = 0;
- pgdat->active_node_migrate = 0;
- pgdat->numabalancing_migrate_next_window = jiffies;
-#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
spin_lock_init(>split_queue_lock);
INIT_LIST_HEAD(>split_queue);
--
Mel Gorman
SUSE Labs
396.58 454.37 421.13 19.71 -1.53%
> numa05.sh Sys: 208.72 422.02 348.90 73.60 -14.7%
> numa05.sh User:33124.0836109.3534846.47 1089.74 -1.79%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
396.58 454.37 421.13 19.71 -1.53%
> numa05.sh Sys: 208.72 422.02 348.90 73.60 -14.7%
> numa05.sh User:33124.0836109.3534846.47 1089.74 -1.79%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
numa_scan_period = task_scan_start(p);
Note too that the next scan can be an arbitrary amount of time in the
future. Consider as an alternative to schedule an immediate scan instead
of adjusting the rate with
p->mm->numa_next_scan = jiffies;
That might be less harmful in terms of overhead while still collecting
some data in the short-term.
--
Mel Gorman
SUSE Labs
numa_scan_period = task_scan_start(p);
Note too that the next scan can be an arbitrary amount of time in the
future. Consider as an alternative to schedule an immediate scan instead
of adjusting the rate with
p->mm->numa_next_scan = jiffies;
That might be less harmful in terms of overhead while still collecting
some data in the short-term.
--
Mel Gorman
SUSE Labs
005 on a 4 node machine and comparing bops/JVM
> JVMS LAST_PATCH WITH_PATCH %CHANGE
> 1625355.9 25645.4 1.141
> 1 72812 72142 -0.92
>
> Reviewed-by: Rik van Riel
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
005 on a 4 node machine and comparing bops/JVM
> JVMS LAST_PATCH WITH_PATCH %CHANGE
> 1625355.9 25645.4 1.141
> 1 72812 72142 -0.92
>
> Reviewed-by: Rik van Riel
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
; numa05.sh Real: 386.77 448.90 417.22 22.79 -3.24%
> numa05.sh Sys: 149.23 379.95 303.04 79.55 -11.3%
> numa05.sh User:32951.7635959.5834562.18 1034.05 -1.65%
>
> Signed-off-by: Srikar Dronamraju
Acked-by:
; numa05.sh Real: 386.77 448.90 417.22 22.79 -3.24%
> numa05.sh Sys: 149.23 379.95 303.04 79.55 -11.3%
> numa05.sh User:32951.7635959.5834562.18 1034.05 -1.65%
>
> Signed-off-by: Srikar Dronamraju
Acked-by:
9 329.15 265.87 61.78 38.92%
> numa05.sh User:33182.6536654.5335074.51 1187.71 3.368%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
9 329.15 265.87 61.78 38.92%
> numa05.sh User:33182.6536654.5335074.51 1187.71 3.368%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
of overall performance.
--
Mel Gorman
SUSE Labs
of overall performance.
--
Mel Gorman
SUSE Labs
375.79 316.23 48.58 5.8343%
> numa04.sh User:35403.1241004.1039720.80 2163.08 -1.153%
> numa05.sh Real: 423.09 460.41 439.57 13.92 -1.428%
> numa05.sh Sys: 287.38 480.15 369.37 68.52 -7.964%
> numa
375.79 316.23 48.58 5.8343%
> numa04.sh User:35403.1241004.1039720.80 2163.08 -1.153%
> numa05.sh Real: 423.09 460.41 439.57 13.92 -1.428%
> numa05.sh Sys: 287.38 480.15 369.37 68.52 -7.964%
> numa
.sh Sys: 144.29 438.56 278.80 105.78 40.77%
> numa05.sh User:33255.8636890.8234879.31 1641.98 12.11%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
.sh Sys: 144.29 438.56 278.80 105.78 40.77%
> numa05.sh User:33255.8636890.8234879.31 1641.98 12.11%
>
> Signed-off-by: Srikar Dronamraju
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
ry workload.
I'll experiement a bit with faster migrations on cross-node accesses
but I think no matter which way we jump on this one it'll be a case of
"it helps one workload and hurts another".
--
Mel Gorman
SUSE Labs
ry workload.
I'll experiement a bit with faster migrations on cross-node accesses
but I think no matter which way we jump on this one it'll be a case of
"it helps one workload and hurts another".
--
Mel Gorman
SUSE Labs
gned int ratelimit_pages __read_mostly = 128 << (20 - PAGE_SHIFT);
+static unsigned int ratelimit_pages __read_mostly = 512 << (20 - PAGE_SHIFT);
/* Returns true if the node is migrate rate-limited after the update */
static bool numamigrate_update_ratelimit(pg_data_t *pgdat,
--
Mel Gorman
SUSE Labs
gned int ratelimit_pages __read_mostly = 128 << (20 - PAGE_SHIFT);
+static unsigned int ratelimit_pages __read_mostly = 512 << (20 - PAGE_SHIFT);
/* Returns true if the node is migrate rate-limited after the update */
static bool numamigrate_update_ratelimit(pg_data_t *pgdat,
--
Mel Gorman
SUSE Labs
ow:
>
Nice one, thanks. It's fairly clear that rate limiting may be a major
component and it's worth testing with the ratelimit increased. Given that
there have been a lot of improvements on locality and corner cases since
the rate limit was first introduced, it may also be worth considering
elimintating the rate limiting entirely and see what falls out.
--
Mel Gorman
SUSE Labs
ow:
>
Nice one, thanks. It's fairly clear that rate limiting may be a major
component and it's worth testing with the ratelimit increased. Given that
there have been a lot of improvements on locality and corner cases since
the rate limit was first introduced, it may also be worth considering
elimintating the rate limiting entirely and see what falls out.
--
Mel Gorman
SUSE Labs
from migrating. If
it's high frequency then you could test increasing ratelimit_pages (which
is set at compile time despite not being a macro). It still may not work
for tasks that are too short-lived to have enough time to identify a
misplacement and migration.
--
Mel Gorman
SUSE Labs
from migrating. If
it's high frequency then you could test increasing ratelimit_pages (which
is set at compile time despite not being a macro). It still may not work
for tasks that are too short-lived to have enough time to identify a
misplacement and migration.
--
Mel Gorman
SUSE Labs
PATCH 17/19] sched/numa: Pass destination cpu as a parameter
to migrate_task_rq
Srikar Dronamra [PATCH 18/19] sched/numa: Reset scan rate whenever task moves
across nodes
--
Mel Gorman
SUSE Labs
PATCH 17/19] sched/numa: Pass destination cpu as a parameter
to migrate_task_rq
Srikar Dronamra [PATCH 18/19] sched/numa: Reset scan rate whenever task moves
across nodes
--
Mel Gorman
SUSE Labs
901 - 1000 of 10256 matches
Mail list logo
