Michael Ellerman writes:
> Nathan Lynch writes:
>> "Aneesh Kumar K.V" writes:
Just checking: do people still need numa=off? Seems like it's a
maintenance burden :-)
>>>
>>> That is used in kdump kernel.
>>
>> I see, thanks.
>
> That doesn't mean it's a good idea :)
>
> Does it ac
Nathan Lynch writes:
> "Aneesh Kumar K.V" writes:
>>> Just checking: do people still need numa=off? Seems like it's a
>>> maintenance burden :-)
>>>
>>
>> That is used in kdump kernel.
>
> I see, thanks.
That doesn't mean it's a good idea :)
Does it actually reduce memory usage much? Last time
"Aneesh Kumar K.V" writes:
>> Just checking: do people still need numa=off? Seems like it's a
>> maintenance burden :-)
>>
>
> That is used in kdump kernel.
I see, thanks.
On 7/1/19 10:12 PM, Nathan Lynch wrote:
"Aneesh Kumar K.V" writes:
I guess we should have here.
modified arch/powerpc/mm/numa.c
@@ -416,12 +416,11 @@ static int of_get_assoc_arrays(struct assoc_arrays
*aa)
static int of_drconf_to_nid_single(struct drmem_lmb *lmb)
{
struct assoc
"Aneesh Kumar K.V" writes:
> I guess we should have here.
>
> modified arch/powerpc/mm/numa.c
> @@ -416,12 +416,11 @@ static int of_get_assoc_arrays(struct assoc_arrays
> *aa)
> static int of_drconf_to_nid_single(struct drmem_lmb *lmb)
> {
> struct assoc_arrays aa = { .arrays = NULL }
On 6/29/19 2:06 PM, Aneesh Kumar K.V wrote:
If we boot with numa=off, we need to make sure we return NUMA_NO_NODE when
looking up associativity details of resources. Without this, we hit crash
like below
BUG: Unable to handle kernel data access at 0x408
Faulting instruction address: 0xc0
If we boot with numa=off, we need to make sure we return NUMA_NO_NODE when
looking up associativity details of resources. Without this, we hit crash
like below
BUG: Unable to handle kernel data access at 0x408
Faulting instruction address: 0xc8f31704
cpu 0x1b: Vector: 380 (Data SLB
