On Sat, Jul 06, 2013 at 12:14:08PM +0530, Srikar Dronamraju wrote:
> * Peter Zijlstra [2013-07-02 20:17:32]:
>
> > On Tue, Jul 02, 2013 at 05:36:55PM +0530, Srikar Dronamraju wrote:
> > > Here, moving tasks this way doesnt update the schedstats at all.
> >
> > Do you actually use schedstats?
>
* Peter Zijlstra [2013-07-02 20:17:32]:
> On Tue, Jul 02, 2013 at 05:36:55PM +0530, Srikar Dronamraju wrote:
> > Here, moving tasks this way doesnt update the schedstats at all.
>
> Do you actually use schedstats?
>
Yes, I do use schedstats. Are there any plans to obsolete it?
It gave me goo
On Wed, Jul 03, 2013 at 04:28:21PM +0100, Mel Gorman wrote:
> I reshuffled the v2 series a bit to match your implied preference for layout
> and rebased this on top of the end result. May not have the beans to
> absorb it before I quit for the evening but I'll at least queue it up
> overnight.
It
On Wed, Jul 03, 2013 at 11:50:59AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 02, 2013 at 08:15:22PM +0200, Peter Zijlstra wrote:
> >
> >
> > Something like this should avoid tasks being lumped back onto one node..
> >
> > Compile tested only, need food.
>
> OK, this one actually ran on my syst
On Tue, Jul 02, 2013 at 08:15:22PM +0200, Peter Zijlstra wrote:
>
>
> Something like this should avoid tasks being lumped back onto one node..
>
> Compile tested only, need food.
OK, this one actually ran on my system and showed no negative effects on
numa02 -- then again, I didn't have the pro
On Tue, Jul 02, 2013 at 05:36:55PM +0530, Srikar Dronamraju wrote:
> Here, moving tasks this way doesnt update the schedstats at all.
Do you actually use schedstats?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
Something like this should avoid tasks being lumped back onto one node..
Compile tested only, need food.
---
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1037,6 +1037,23 @@ struct migration_arg {
static int migration_cpu_stop(void *data);
+#ifdef CONFIG_NUMA_BALANCING
+int migra
On Tue, Jul 02, 2013 at 05:36:55PM +0530, Srikar Dronamraju wrote:
> > A preferred node is selected based on the node the most NUMA hinting
> > faults was incurred on. There is no guarantee that the task is running
> > on that node at the time so this patch rescheules the task to run on
> > the mos
> A preferred node is selected based on the node the most NUMA hinting
> faults was incurred on. There is no guarantee that the task is running
> on that node at the time so this patch rescheules the task to run on
> the most idle CPU of the selected node when selected. This avoids
> waiting for th
On Thu, Jun 27, 2013 at 04:54:58PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 26, 2013 at 03:38:05PM +0100, Mel Gorman wrote:
> > +static int
> > +find_idlest_cpu_node(int this_cpu, int nid)
> > +{
> > + unsigned long load, min_load = ULONG_MAX;
> > + int i, idlest_cpu = this_cpu;
> > +
> > +
On Wed, Jun 26, 2013 at 03:38:05PM +0100, Mel Gorman wrote:
> +static int
> +find_idlest_cpu_node(int this_cpu, int nid)
> +{
> + unsigned long load, min_load = ULONG_MAX;
> + int i, idlest_cpu = this_cpu;
> +
> + BUG_ON(cpu_to_node(this_cpu) == nid);
> +
> + for_each_cpu(i, cpumask
A preferred node is selected based on the node the most NUMA hinting
faults was incurred on. There is no guarantee that the task is running
on that node at the time so this patch rescheules the task to run on
the most idle CPU of the selected node when selected. This avoids
waiting for the balancer
12 matches
Mail list logo
