Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


yinghai at kernel

May 14, 2009, 9:43 AM

Post #1 of 6 (1050 views)
Permalink
[PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2

incase some system strange SRAT table. some kind of small range.
or with mem= etc

v2: fix typo

Signed-off-by: Yinghai Lu <Yinghai [at] kernel>
Tested-by: Jack Steiner <steiner [at] sgi>

---
mm/page_alloc.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -4041,6 +4047,11 @@ void __init free_area_init_nodes(unsigne
early_node_map[i].start_pfn,
early_node_map[i].end_pfn);

+ /*
+ * find_zone_movable_pfns_for_nodes/early_calculate_totalpages init
+ * that node_mask, clear it at first
+ */
+ nodes_clear(node_states[N_HIGH_MEMORY]);
/* Initialise every node */
mminit_verify_pageflags_layout();
setup_nr_node_ids();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


akpm at linux-foundation

May 14, 2009, 9:54 AM

Post #2 of 6 (982 views)
Permalink
Re: [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 [In reply to]

On Thu, 14 May 2009 09:43:22 -0700
Yinghai Lu <yinghai [at] kernel> wrote:

>
> incase some system strange SRAT table. some kind of small range.
> or with mem= etc
>

That description is very hard to understand. Please provide more details.

>
> Signed-off-by: Yinghai Lu <Yinghai [at] kernel>
> Tested-by: Jack Steiner <steiner [at] sgi>

What reason did Jack have to test this? Perhaps he hit some bug?
If so, please fully describe that bug in the changelog.


> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -4041,6 +4047,11 @@ void __init free_area_init_nodes(unsigne
> early_node_map[i].start_pfn,
> early_node_map[i].end_pfn);
>
> + /*
> + * find_zone_movable_pfns_for_nodes/early_calculate_totalpages init
> + * that node_mask, clear it at first
> + */
> + nodes_clear(node_states[N_HIGH_MEMORY]);
> /* Initialise every node */
> mminit_verify_pageflags_layout();
> setup_nr_node_ids();

If CONFIG_HIGHMEM=n, this will clear the N_NORMAL_MEMORY entry in
node_states[]. Why is this correct and desirable?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


yinghai at kernel

May 14, 2009, 10:05 AM

Post #3 of 6 (982 views)
Permalink
Re: [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 [In reply to]

Andrew Morton wrote:
> On Thu, 14 May 2009 09:43:22 -0700
> Yinghai Lu <yinghai [at] kernel> wrote:
>
>> incase some system strange SRAT table. some kind of small range.
>> or with mem= etc
>>
>
> That description is very hard to understand. Please provide more details.

if the wrong SRAT table, have small range for some node. that node will not be onlined.
In the early checking, the bit in node_states[N_HIGH_MEMORY] for the node is set even
that node has less RAM like 1M, and it is not cleared before the bit is set again in
the following loop according online nodes.

>
>> Signed-off-by: Yinghai Lu <Yinghai [at] kernel>
>> Tested-by: Jack Steiner <steiner [at] sgi>
>
> What reason did Jack have to test this? Perhaps he hit some bug?
> If so, please fully describe that bug in the changelog.

for some memmoryless node and strange memmap.

>
>
>> Index: linux-2.6/mm/page_alloc.c
>> ===================================================================
>> --- linux-2.6.orig/mm/page_alloc.c
>> +++ linux-2.6/mm/page_alloc.c
>> @@ -4041,6 +4047,11 @@ void __init free_area_init_nodes(unsigne
>> early_node_map[i].start_pfn,
>> early_node_map[i].end_pfn);
>>
>> + /*
>> + * find_zone_movable_pfns_for_nodes/early_calculate_totalpages init
>> + * that node_mask, clear it at first
>> + */
>> + nodes_clear(node_states[N_HIGH_MEMORY]);
>> /* Initialise every node */
>> mminit_verify_pageflags_layout();
>> setup_nr_node_ids();
>
> If CONFIG_HIGHMEM=n, this will clear the N_NORMAL_MEMORY entry in
> node_states[]. Why is this correct and desirable?

then N_NORMAL_MEMORY == N_HIGH_MEMORY

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


akpm at linux-foundation

May 14, 2009, 10:25 AM

Post #4 of 6 (973 views)
Permalink
Re: [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 [In reply to]

On Thu, 14 May 2009 10:05:43 -0700
Yinghai Lu <yinghai [at] kernel> wrote:

> Andrew Morton wrote:
> > On Thu, 14 May 2009 09:43:22 -0700
> > Yinghai Lu <yinghai [at] kernel> wrote:
> >
> >> incase some system strange SRAT table. some kind of small range.
> >> or with mem= etc
> >>
> >
> > That description is very hard to understand. Please provide more details.
>
> if the wrong SRAT table, have small range for some node. that node will not be onlined.
> In the early checking, the bit in node_states[N_HIGH_MEMORY] for the node is set even
> that node has less RAM like 1M, and it is not cleared before the bit is set again in
> the following loop according online nodes.

Where in the kernel does this setting of the bit in node_states[]
occur? early_calculate_totalpages()?

Where in the kernel is it later decided to _not_ use these pages in
that node? Perhaps that's the place where the problem should be fixed.


> >
> >> Signed-off-by: Yinghai Lu <Yinghai [at] kernel>
> >> Tested-by: Jack Steiner <steiner [at] sgi>
> >
> > What reason did Jack have to test this? Perhaps he hit some bug?
> > If so, please fully describe that bug in the changelog.
>
> for some memmoryless node and strange memmap.

That's not a very good problem description.

Put yourself in the position of a distro engineer whose customer
reports a 2.6.26 problem. He's going to look at your patch wondering
whether it might fix his customer's problem. We should provide him
with sufficient information to be able to determine this.

> >
> >
> >> Index: linux-2.6/mm/page_alloc.c
> >> ===================================================================
> >> --- linux-2.6.orig/mm/page_alloc.c
> >> +++ linux-2.6/mm/page_alloc.c
> >> @@ -4041,6 +4047,11 @@ void __init free_area_init_nodes(unsigne
> >> early_node_map[i].start_pfn,
> >> early_node_map[i].end_pfn);
> >>
> >> + /*
> >> + * find_zone_movable_pfns_for_nodes/early_calculate_totalpages init
> >> + * that node_mask, clear it at first
> >> + */
> >> + nodes_clear(node_states[N_HIGH_MEMORY]);
> >> /* Initialise every node */
> >> mminit_verify_pageflags_layout();
> >> setup_nr_node_ids();
> >
> > If CONFIG_HIGHMEM=n, this will clear the N_NORMAL_MEMORY entry in
> > node_states[]. Why is this correct and desirable?
>
> then N_NORMAL_MEMORY == N_HIGH_MEMORY

I know.

But it's unobvious that this change is correct and desirable with both
CONFIG_HIGHMEM=n and CONFIG_HIGHMEM=y.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


yinghai at kernel

May 14, 2009, 10:34 AM

Post #5 of 6 (971 views)
Permalink
Re: [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 [In reply to]

Andrew Morton wrote:
> On Thu, 14 May 2009 10:05:43 -0700
> Yinghai Lu <yinghai [at] kernel> wrote:
>
>> Andrew Morton wrote:
>>> On Thu, 14 May 2009 09:43:22 -0700
>>> Yinghai Lu <yinghai [at] kernel> wrote:
>>>
>>>> incase some system strange SRAT table. some kind of small range.
>>>> or with mem= etc
>>>>
>>> That description is very hard to understand. Please provide more details.
>> if the wrong SRAT table, have small range for some node. that node will not be onlined.
>> In the early checking, the bit in node_states[N_HIGH_MEMORY] for the node is set even
>> that node has less RAM like 1M, and it is not cleared before the bit is set again in
>> the following loop according online nodes.
>
> Where in the kernel does this setting of the bit in node_states[]
> occur? early_calculate_totalpages()?

yes.

>
> Where in the kernel is it later decided to _not_ use these pages in
> that node? Perhaps that's the place where the problem should be fixed.

in free_area_init_nodes()

/* Initialise every node */
mminit_verify_pageflags_layout();
setup_nr_node_ids();
for_each_online_node(nid) {
pg_data_t *pgdat = NODE_DATA(nid);
free_area_init_node(nid, NULL,
find_min_pfn_for_node(nid), NULL);

/* Any memory on that node */
if (pgdat->node_present_pages)
node_set_state(nid, N_HIGH_MEMORY);
check_for_regular_memory(pgdat);
}

so that patch clear that node_mask before set those bits according if that node is online
and node_present_pages is there.

>
>
>>>> Signed-off-by: Yinghai Lu <Yinghai [at] kernel>
>>>> Tested-by: Jack Steiner <steiner [at] sgi>
>>> What reason did Jack have to test this? Perhaps he hit some bug?
>>> If so, please fully describe that bug in the changelog.
>> for some memmoryless node and strange memmap.
>
> That's not a very good problem description.
>
> Put yourself in the position of a distro engineer whose customer
> reports a 2.6.26 problem. He's going to look at your patch wondering
> whether it might fix his customer's problem. We should provide him
> with sufficient information to be able to determine this.
>
>>>
>>>> Index: linux-2.6/mm/page_alloc.c
>>>> ===================================================================
>>>> --- linux-2.6.orig/mm/page_alloc.c
>>>> +++ linux-2.6/mm/page_alloc.c
>>>> @@ -4041,6 +4047,11 @@ void __init free_area_init_nodes(unsigne
>>>> early_node_map[i].start_pfn,
>>>> early_node_map[i].end_pfn);
>>>>
>>>> + /*
>>>> + * find_zone_movable_pfns_for_nodes/early_calculate_totalpages init
>>>> + * that node_mask, clear it at first
>>>> + */
>>>> + nodes_clear(node_states[N_HIGH_MEMORY]);
>>>> /* Initialise every node */
>>>> mminit_verify_pageflags_layout();
>>>> setup_nr_node_ids();
>>> If CONFIG_HIGHMEM=n, this will clear the N_NORMAL_MEMORY entry in
>>> node_states[]. Why is this correct and desirable?
>> then N_NORMAL_MEMORY == N_HIGH_MEMORY
>
> I know.
>
> But it's unobvious that this change is correct and desirable with both
> CONFIG_HIGHMEM=n and CONFIG_HIGHMEM=y.

use ifdef ?

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


cl at linux-foundation

May 14, 2009, 12:44 PM

Post #6 of 6 (974 views)
Permalink
Re: [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 [In reply to]

On Thu, 14 May 2009, Yinghai Lu wrote:

> > Put yourself in the position of a distro engineer whose customer
> > reports a 2.6.26 problem. He's going to look at your patch wondering
> > whether it might fix his customer's problem. We should provide him
> > with sufficient information to be able to determine this.

PowerPC has similar node 0 issues that have thrown us for a curve once in
awhile. Now they are coming to x86.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.