Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-09 Thread Mel Gorman 
On Fri, Nov 09, 2012 at 03:42:57PM +0100, Andrea Arcangeli wrote:
> Hi Mel,
> 
> On Tue, Nov 06, 2012 at 09:14:36AM +, Mel Gorman wrote:
> > This series addresses part of the integration and sharing problem by
> > implementing a foundation that either the policy for schednuma or autonuma
> > can be rebased on. The actual policy it implements is a very stupid
> > greedy policy called "Migrate On Reference Of pte_numa Node (MORON)".
> > While stupid, it can be faster than the vanilla kernel and the expectation
> > is that any clever policy should be able to beat MORON. The advantage is
> > that it still defines how the policy needs to hook into the core code --
> > scheduler and mempolicy mostly so many optimisations (s uch as native THP
> > migration) can be shared between different policy implementations.
> 
> I haven't had much time to look into it yet, because I've been
> attending KVM Forum the last few days,

That's fine. I knew you were travelling and that there would be delay.

> but this foundation looks ok
> with me as a starting base and I ack it for merging it upstream. I'll
> try to rebase on top of this and send you some patches.
> 

Thanks, that's great news! It's not quite ready for merging yet. I found
a few bugs in the foundation that I ironed out since and I would like to
have better figures for specjbb.

With that in mind I'm still in the process of implementing something like
cpu-follow-memory on top. I'll post it early next week even if the figures
are crap for the purposes of illustration and to get the existing fixes
out there. Even you think the version of the cpu-follow implementation is
complete crap you'll at least see what I thought the integration points
would look like and we'll come up with an alternative.

My hope is that we layer the smallest amount on top each iteration with
benchmark validation at each step until we get something approaching
autonuma or schednumas in terms of performance. Which one we use as the
performance target will depend on whether schednuma or autonuma was better
on that particular test. I'll be using mmtests on a 4-node machine each
step but obviously other testers would be very welcome.

As things stand right now I just finished a script to show where threads
and running and what their per-node memory usage is and it's showing that
specjbb threads are not converging at all. I'm not losing sleep over it
just yet as I would be incredibly surprised if I got this right first time
even with having schednuma and autonuma to look at :) .

> > Patch 14 adds a MPOL_MF_LAZY mempolicy that an interested application can 
> > use.
> > On the next reference the memory should be migrated to the node that
> > references the memory.
> 
> This approach of starting with a stripped down foundation won't allow
> for easy backportability anyway, so merging the userland API at the
> first step shouldn't provide any benefit for the work that is ahead of
> us. I would leave this for later and not part of the foundation.
> 

This needs a bit more consensus. I'm happy to drop the userspace API
until all this settles down but will initially try and keep the internal
mempolicy aspects.  Initially I preserved the userspace API because
I understood Peter's logic that we should help application developers
as much as possible before depending entirely on the automatic approach
offered by both autonuma and schednuma.

Peter?

> All we need is a failsafe runtime and boot time turn off knob, just in
> case.

Yes, fully agreed. It's on the TODO list and I consider it a requirement
before it's merged. THP experience has told us that being able to turn
it off at runtime was very handy for debugging.

Thanks Andrea.

-- 
Mel Gorman
SUSE Labs
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-09 Thread Andrea Arcangeli 
Hi Mel,

On Tue, Nov 06, 2012 at 09:14:36AM +, Mel Gorman wrote:
> This series addresses part of the integration and sharing problem by
> implementing a foundation that either the policy for schednuma or autonuma
> can be rebased on. The actual policy it implements is a very stupid
> greedy policy called "Migrate On Reference Of pte_numa Node (MORON)".
> While stupid, it can be faster than the vanilla kernel and the expectation
> is that any clever policy should be able to beat MORON. The advantage is
> that it still defines how the policy needs to hook into the core code --
> scheduler and mempolicy mostly so many optimisations (s uch as native THP
> migration) can be shared between different policy implementations.

I haven't had much time to look into it yet, because I've been
attending KVM Forum the last few days, but this foundation looks ok
with me as a starting base and I ack it for merging it upstream. I'll
try to rebase on top of this and send you some patches.

> Patch 14 adds a MPOL_MF_LAZY mempolicy that an interested application can use.
>   On the next reference the memory should be migrated to the node that
>   references the memory.

This approach of starting with a stripped down foundation won't allow
for easy backportability anyway, so merging the userland API at the
first step shouldn't provide any benefit for the work that is ahead of
us. I would leave this for later and not part of the foundation.

All we need is a failsafe runtime and boot time turn off knob, just in
case.

Thanks,
Andrea
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-09 Thread Andrea Arcangeli 
Hi Mel,

On Tue, Nov 06, 2012 at 09:14:36AM +, Mel Gorman wrote:
 This series addresses part of the integration and sharing problem by
 implementing a foundation that either the policy for schednuma or autonuma
 can be rebased on. The actual policy it implements is a very stupid
 greedy policy called Migrate On Reference Of pte_numa Node (MORON).
 While stupid, it can be faster than the vanilla kernel and the expectation
 is that any clever policy should be able to beat MORON. The advantage is
 that it still defines how the policy needs to hook into the core code --
 scheduler and mempolicy mostly so many optimisations (s uch as native THP
 migration) can be shared between different policy implementations.

I haven't had much time to look into it yet, because I've been
attending KVM Forum the last few days, but this foundation looks ok
with me as a starting base and I ack it for merging it upstream. I'll
try to rebase on top of this and send you some patches.

 Patch 14 adds a MPOL_MF_LAZY mempolicy that an interested application can use.
   On the next reference the memory should be migrated to the node that
   references the memory.

This approach of starting with a stripped down foundation won't allow
for easy backportability anyway, so merging the userland API at the
first step shouldn't provide any benefit for the work that is ahead of
us. I would leave this for later and not part of the foundation.

All we need is a failsafe runtime and boot time turn off knob, just in
case.

Thanks,
Andrea
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-09 Thread Mel Gorman 
On Fri, Nov 09, 2012 at 03:42:57PM +0100, Andrea Arcangeli wrote:
 Hi Mel,
 
 On Tue, Nov 06, 2012 at 09:14:36AM +, Mel Gorman wrote:
  This series addresses part of the integration and sharing problem by
  implementing a foundation that either the policy for schednuma or autonuma
  can be rebased on. The actual policy it implements is a very stupid
  greedy policy called Migrate On Reference Of pte_numa Node (MORON).
  While stupid, it can be faster than the vanilla kernel and the expectation
  is that any clever policy should be able to beat MORON. The advantage is
  that it still defines how the policy needs to hook into the core code --
  scheduler and mempolicy mostly so many optimisations (s uch as native THP
  migration) can be shared between different policy implementations.
 
 I haven't had much time to look into it yet, because I've been
 attending KVM Forum the last few days,

That's fine. I knew you were travelling and that there would be delay.

 but this foundation looks ok
 with me as a starting base and I ack it for merging it upstream. I'll
 try to rebase on top of this and send you some patches.
 

Thanks, that's great news! It's not quite ready for merging yet. I found
a few bugs in the foundation that I ironed out since and I would like to
have better figures for specjbb.

With that in mind I'm still in the process of implementing something like
cpu-follow-memory on top. I'll post it early next week even if the figures
are crap for the purposes of illustration and to get the existing fixes
out there. Even you think the version of the cpu-follow implementation is
complete crap you'll at least see what I thought the integration points
would look like and we'll come up with an alternative.

My hope is that we layer the smallest amount on top each iteration with
benchmark validation at each step until we get something approaching
autonuma or schednumas in terms of performance. Which one we use as the
performance target will depend on whether schednuma or autonuma was better
on that particular test. I'll be using mmtests on a 4-node machine each
step but obviously other testers would be very welcome.

As things stand right now I just finished a script to show where threads
and running and what their per-node memory usage is and it's showing that
specjbb threads are not converging at all. I'm not losing sleep over it
just yet as I would be incredibly surprised if I got this right first time
even with having schednuma and autonuma to look at :) .

  Patch 14 adds a MPOL_MF_LAZY mempolicy that an interested application can 
  use.
  On the next reference the memory should be migrated to the node that
  references the memory.
 
 This approach of starting with a stripped down foundation won't allow
 for easy backportability anyway, so merging the userland API at the
 first step shouldn't provide any benefit for the work that is ahead of
 us. I would leave this for later and not part of the foundation.
 

This needs a bit more consensus. I'm happy to drop the userspace API
until all this settles down but will initially try and keep the internal
mempolicy aspects.  Initially I preserved the userspace API because
I understood Peter's logic that we should help application developers
as much as possible before depending entirely on the automatic approach
offered by both autonuma and schednuma.

Peter?

 All we need is a failsafe runtime and boot time turn off knob, just in
 case.

Yes, fully agreed. It's on the TODO list and I consider it a requirement
before it's merged. THP experience has told us that being able to turn
it off at runtime was very handy for debugging.

Thanks Andrea.

-- 
Mel Gorman
SUSE Labs
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Zhouping Liu 
On 11/08/2012 02:39 PM, 杨竹 wrote:
> Hi all:
>   I got a problem：
>   1. on intel cpu xeon E5000 family which support xapic ，one NIC
> irq  can share on the CPUs basic on smp_affinity.
>   2. but on intel cpu xeon E5-2600 family which support x2apic, one
> NIC irq only on CPU0 whatever  i set the smp_affinfiy like as "aa"; "55";
> "ff".
>  My OS is CentOS 6.2  x32 ，i test 4 cpus。 the result is which only
> support apic can share one irq to all cpus，which support x2apic only make
> the irq to one cpu。

richard, I'm not sure whether your problem is occurred with the
patch-set or not,
if it's not related to the patches, you should report it on a *new* subject.

Thanks,
Zhouping

>
>
> want help me
>
>  richard
>
>
> 2012/11/8 Zhouping Liu 
>
>> On 11/07/2012 11:25 PM, Mel Gorman wrote:
>>
>>> On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
>>>
 Hello Mel,

 my 2 nodes machine hit a panic fault after applied the patch
 set(based on kernel-3.7.0-rc4), please review it:

 

>>> Early initialisation problem by the looks of things. Try this please
>>>
>> Tested the patch, and the issue is gone.
>>
>>
>>> ---8<---
>>> mm: numa: Check that preferred_node_policy is initialised
>>>
>>> Zhouping Liu reported the following
>>>
>>> [ 0.00] [ cut here ]
>>> [ 0.00] kernel BUG at mm/mempolicy.c:1785!
>>> [ 0.00] invalid opcode:  [#1] SMP
>>> [ 0.00] Modules linked in:
>>> [ 0.00] CPU 0
>>> 
>>> [0.00] Call Trace:
>>> [0.00] [] alloc_pages_current+0xa6/0x170
>>> [0.00] [] __get_free_pages+0x14/0x50
>>> [0.00] [] kmem_cache_init+0x53/0x2d2
>>> [0.00] [] start_kernel+0x1e0/0x3c7
>>>
>>> Problem is that early in boot preferred_nod_policy and SLUB
>>> initialisation trips up. Check it is initialised.
>>>
>>> Signed-off-by: Mel Gorman 
>>>
>> Tested-by: Zhouping Liu 
>>
>> Thanks,
>> Zhouping
>>
>>  ---
>>>   mm/mempolicy.c |4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>>> index 11d4b6b..8cfa6dc 100644
>>> --- a/mm/mempolicy.c
>>> +++ b/mm/mempolicy.c
>>> @@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct
>>> task_struct *p)
>>> node = numa_node_id();
>>> if (node != -1)
>>> pol = _node_policy[node];
>>> +
>>> +   /* preferred_node_policy is not initialised early in boot
>>> */
>>> +   if (!pol->mode)
>>> +   pol = NULL;
>>> }
>>> return pol;
>>>
>>> --
>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>> the body to majord...@kvack.org.  For more info on Linux MM,
>>> see: http://www.linux-mm.org/ .
>>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>>>
>> --
>> 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/**majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>

--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Zhouping Liu 

On 11/07/2012 11:25 PM, Mel Gorman wrote:

On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:

Hello Mel,

my 2 nodes machine hit a panic fault after applied the patch
set(based on kernel-3.7.0-rc4), please review it:



Early initialisation problem by the looks of things. Try this please


Tested the patch, and the issue is gone.



---8<---
mm: numa: Check that preferred_node_policy is initialised

Zhouping Liu reported the following

[ 0.00] [ cut here ]
[ 0.00] kernel BUG at mm/mempolicy.c:1785!
[ 0.00] invalid opcode:  [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU 0

[0.00] Call Trace:
[0.00] [] alloc_pages_current+0xa6/0x170
[0.00] [] __get_free_pages+0x14/0x50
[0.00] [] kmem_cache_init+0x53/0x2d2
[0.00] [] start_kernel+0x1e0/0x3c7

Problem is that early in boot preferred_nod_policy and SLUB
initialisation trips up. Check it is initialised.

Signed-off-by: Mel Gorman 


Tested-by: Zhouping Liu 

Thanks,
Zhouping


---
  mm/mempolicy.c |4 
  1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 11d4b6b..8cfa6dc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct 
task_struct *p)
node = numa_node_id();
if (node != -1)
pol = _node_policy[node];
+
+   /* preferred_node_policy is not initialised early in boot */
+   if (!pol->mode)
+   pol = NULL;
}
  
  	return pol;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 


--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Mel Gorman 
On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
> 
> Hello Mel,
> 
> my 2 nodes machine hit a panic fault after applied the patch
> set(based on kernel-3.7.0-rc4), please review it:
> 
> 

Early initialisation problem by the looks of things. Try this please

---8<---
mm: numa: Check that preferred_node_policy is initialised

Zhouping Liu reported the following

[ 0.00] [ cut here ]
[ 0.00] kernel BUG at mm/mempolicy.c:1785!
[ 0.00] invalid opcode:  [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU 0

[0.00] Call Trace:
[0.00] [] alloc_pages_current+0xa6/0x170
[0.00] [] __get_free_pages+0x14/0x50
[0.00] [] kmem_cache_init+0x53/0x2d2
[0.00] [] start_kernel+0x1e0/0x3c7

Problem is that early in boot preferred_nod_policy and SLUB
initialisation trips up. Check it is initialised.

Signed-off-by: Mel Gorman 
---
 mm/mempolicy.c |4 
 1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 11d4b6b..8cfa6dc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct 
task_struct *p)
node = numa_node_id();
if (node != -1)
pol = _node_policy[node];
+
+   /* preferred_node_policy is not initialised early in boot */
+   if (!pol->mode)
+   pol = NULL;
}
 
return pol;
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Mel Gorman 
On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
 
 Hello Mel,
 
 my 2 nodes machine hit a panic fault after applied the patch
 set(based on kernel-3.7.0-rc4), please review it:
 
 SNIP

Early initialisation problem by the looks of things. Try this please

---8---
mm: numa: Check that preferred_node_policy is initialised

Zhouping Liu reported the following

[ 0.00] [ cut here ]
[ 0.00] kernel BUG at mm/mempolicy.c:1785!
[ 0.00] invalid opcode:  [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU 0

[0.00] Call Trace:
[0.00] [81176966] alloc_pages_current+0xa6/0x170
[0.00] [81137a44] __get_free_pages+0x14/0x50
[0.00] [819efd9b] kmem_cache_init+0x53/0x2d2
[0.00] [819caa53] start_kernel+0x1e0/0x3c7

Problem is that early in boot preferred_nod_policy and SLUB
initialisation trips up. Check it is initialised.

Signed-off-by: Mel Gorman mgor...@suse.de
---
 mm/mempolicy.c |4 
 1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 11d4b6b..8cfa6dc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct 
task_struct *p)
node = numa_node_id();
if (node != -1)
pol = preferred_node_policy[node];
+
+   /* preferred_node_policy is not initialised early in boot */
+   if (!pol-mode)
+   pol = NULL;
}
 
return pol;
--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Zhouping Liu 

On 11/07/2012 11:25 PM, Mel Gorman wrote:

On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:

Hello Mel,

my 2 nodes machine hit a panic fault after applied the patch
set(based on kernel-3.7.0-rc4), please review it:

SNIP

Early initialisation problem by the looks of things. Try this please


Tested the patch, and the issue is gone.



---8---
mm: numa: Check that preferred_node_policy is initialised

Zhouping Liu reported the following

[ 0.00] [ cut here ]
[ 0.00] kernel BUG at mm/mempolicy.c:1785!
[ 0.00] invalid opcode:  [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU 0

[0.00] Call Trace:
[0.00] [81176966] alloc_pages_current+0xa6/0x170
[0.00] [81137a44] __get_free_pages+0x14/0x50
[0.00] [819efd9b] kmem_cache_init+0x53/0x2d2
[0.00] [819caa53] start_kernel+0x1e0/0x3c7

Problem is that early in boot preferred_nod_policy and SLUB
initialisation trips up. Check it is initialised.

Signed-off-by: Mel Gorman mgor...@suse.de


Tested-by: Zhouping Liu z...@redhat.com

Thanks,
Zhouping


---
  mm/mempolicy.c |4 
  1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 11d4b6b..8cfa6dc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct 
task_struct *p)
node = numa_node_id();
if (node != -1)
pol = preferred_node_policy[node];
+
+   /* preferred_node_policy is not initialised early in boot */
+   if (!pol-mode)
+   pol = NULL;
}
  
  	return pol;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a


--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

2012-11-07 Thread Zhouping Liu 
On 11/08/2012 02:39 PM, 杨竹 wrote:
 Hi all:
   I got a problem：
   1. on intel cpu xeon E5000 family which support xapic ，one NIC
 irq  can share on the CPUs basic on smp_affinity.
   2. but on intel cpu xeon E5-2600 family which support x2apic, one
 NIC irq only on CPU0 whatever  i set the smp_affinfiy like as aa; 55;
 ff.
  My OS is CentOS 6.2  x32 ，i test 4 cpus。 the result is which only
 support apic can share one irq to all cpus，which support x2apic only make
 the irq to one cpu。

richard, I'm not sure whether your problem is occurred with the
patch-set or not,
if it's not related to the patches, you should report it on a *new* subject.

Thanks,
Zhouping



 want help me

  richard


 2012/11/8 Zhouping Liu z...@redhat.com

 On 11/07/2012 11:25 PM, Mel Gorman wrote:

 On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:

 Hello Mel,

 my 2 nodes machine hit a panic fault after applied the patch
 set(based on kernel-3.7.0-rc4), please review it:

 SNIP

 Early initialisation problem by the looks of things. Try this please

 Tested the patch, and the issue is gone.


 ---8---
 mm: numa: Check that preferred_node_policy is initialised

 Zhouping Liu reported the following

 [ 0.00] [ cut here ]
 [ 0.00] kernel BUG at mm/mempolicy.c:1785!
 [ 0.00] invalid opcode:  [#1] SMP
 [ 0.00] Modules linked in:
 [ 0.00] CPU 0
 
 [0.00] Call Trace:
 [0.00] [81176966] alloc_pages_current+0xa6/0x170
 [0.00] [81137a44] __get_free_pages+0x14/0x50
 [0.00] [819efd9b] kmem_cache_init+0x53/0x2d2
 [0.00] [819caa53] start_kernel+0x1e0/0x3c7

 Problem is that early in boot preferred_nod_policy and SLUB
 initialisation trips up. Check it is initialised.

 Signed-off-by: Mel Gorman mgor...@suse.de

 Tested-by: Zhouping Liu z...@redhat.com

 Thanks,
 Zhouping

  ---
   mm/mempolicy.c |4 
   1 file changed, 4 insertions(+)

 diff --git a/mm/mempolicy.c b/mm/mempolicy.c
 index 11d4b6b..8cfa6dc 100644
 --- a/mm/mempolicy.c
 +++ b/mm/mempolicy.c
 @@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct
 task_struct *p)
 node = numa_node_id();
 if (node != -1)
 pol = preferred_node_policy[node];
 +
 +   /* preferred_node_policy is not initialised early in boot
 */
 +   if (!pol-mode)
 +   pol = NULL;
 }
 return pol;

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a

 --
 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/**majordomo-info.htmlhttp://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


--
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/