Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-25 Thread Mel Gorman
On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: > From: Rik van Riel > > Setting the numa_preferred_node for a task in task_numa_migrate > does nothing on a 2-node system. Either we migrate to the node > that already was our preferred node, or we stay where we were. > > On a

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-25 Thread Mel Gorman
On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: From: Rik van Riel r...@redhat.com Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node, or we stay where we were.

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-15 Thread Peter Zijlstra
On Tue, Apr 15, 2014 at 10:35:29AM -0400, Rik van Riel wrote: > I have looked at the comment and the changelog some > more, and it is not clear to me what you are missing, > or what I could be explaining better... Yeah, can't blame you. I couldn't explain myself either, other than having this

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-15 Thread Rik van Riel
On 04/14/2014 08:56 AM, Peter Zijlstra wrote: On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: From: Rik van Riel Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node,

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-15 Thread Rik van Riel
On 04/14/2014 08:56 AM, Peter Zijlstra wrote: On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: From: Rik van Riel r...@redhat.com Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-15 Thread Peter Zijlstra
On Tue, Apr 15, 2014 at 10:35:29AM -0400, Rik van Riel wrote: I have looked at the comment and the changelog some more, and it is not clear to me what you are missing, or what I could be explaining better... Yeah, can't blame you. I couldn't explain myself either, other than having this

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-14 Thread Peter Zijlstra
On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: > From: Rik van Riel > > Setting the numa_preferred_node for a task in task_numa_migrate > does nothing on a 2-node system. Either we migrate to the node > that already was our preferred node, or we stay where we were. > > On a

Re: [PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-14 Thread Peter Zijlstra
On Fri, Apr 11, 2014 at 01:00:29PM -0400, r...@redhat.com wrote: From: Rik van Riel r...@redhat.com Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node, or we stay where we were.

[PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-11 Thread riel
From: Rik van Riel Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node, or we stay where we were. On a 4-node system, it can slightly decrease overhead, by not calling the NUMA code as

[PATCH 3/3] sched,numa: do not set preferred_node on migration to a second choice node

2014-04-11 Thread riel
From: Rik van Riel r...@redhat.com Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node, or we stay where we were. On a 4-node system, it can slightly decrease overhead, by not calling