* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree [not found] <200807280313.m6S3DHDk017400@imap1.linux-foundation.org> @ 2008-07-28 9:16 ` Mel Gorman 2008-07-28 11:15 ` Yinghai Lu 0 siblings, 1 reply; 12+ messages in thread From: Mel Gorman @ 2008-07-28 9:16 UTC (permalink / raw) To: akpm; +Cc: linux-mm, yhlu.kernel On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: > > The patch titled > mm: remove find_max_pfn_with_active_regions > has been added to the -mm tree. Its filename is > mm-remove-find_max_pfn_with_active_regions.patch > > Before you just go and hit "reply", please: > a) Consider who else should be cc'ed > b) Prefer to cc a suitable mailing list as well > c) Ideally: find the original patch on the mailing list and do a > reply-to-all to that, adding suitable additional cc's > > *** Remember to use Documentation/SubmitChecklist when testing your code *** > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > out what to do about this > > The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ > > ------------------------------------------------------ > Subject: mm: remove find_max_pfn_with_active_regions > From: Yinghai Lu <yhlu.kernel@gmail.com> > > It has no user now > > Also print out info about adding/removing active regions. > > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > Cc: Mel Gorman <mel@csn.ul.ie> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > --- > > include/linux/mm.h | 1 - > mm/page_alloc.c | 22 ++-------------------- > 2 files changed, 2 insertions(+), 21 deletions(-) > > diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h > --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions > +++ a/include/linux/mm.h > @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran > extern void get_pfn_range_for_nid(unsigned int nid, > unsigned long *start_pfn, unsigned long *end_pfn); > extern unsigned long find_min_pfn_with_active_regions(void); > -extern unsigned long find_max_pfn_with_active_regions(void); > extern void free_bootmem_with_active_regions(int nid, > unsigned long max_low_pfn); > typedef int (*work_fn_t)(unsigned long, unsigned long, void *); > diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c > --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions > +++ a/mm/page_alloc.c > @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in > { > int i; > > - mminit_dprintk(MMINIT_TRACE, "memory_register", > - "Entering add_active_range(%d, %#lx, %#lx) " > + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " > "%d entries of %d used\n", > nid, start_pfn, end_pfn, > nr_nodemap_entries, MAX_ACTIVE_REGIONS); Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On some machines, this will be very noisy. For example, some POWER configurations will print out one line for every 16MB of memory with this patch. > @@ -3635,7 +3634,7 @@ void __init remove_active_range(unsigned > int i, j; > int removed = 0; > > - printk(KERN_DEBUG "remove_active_range (%d, %lu, %lu)\n", > + printk(KERN_INFO "Removing active range (%d, %#lx, %#lx)\n", > nid, start_pfn, end_pfn); > This call is a lot rarer but I still don't see why it is being moved to KERN_INFO. If anything, that should have been another mminit_printk() call and one I obviously missed. > /* Find the old active region end and shrink */ > @@ -3753,23 +3752,6 @@ unsigned long __init find_min_pfn_with_a > return find_min_pfn_for_node(MAX_NUMNODES); > } > > -/** > - * find_max_pfn_with_active_regions - Find the maximum PFN registered > - * > - * It returns the maximum PFN based on information provided via > - * add_active_range(). > - */ > -unsigned long __init find_max_pfn_with_active_regions(void) > -{ > - int i; > - unsigned long max_pfn = 0; > - > - for (i = 0; i < nr_nodemap_entries; i++) > - max_pfn = max(max_pfn, early_node_map[i].end_pfn); > - > - return max_pfn; > -} > - > /* > * early_calculate_totalpages() > * Sum pages in active regions for movable zone. > _ > > Patches currently in -mm which might be from yhlu.kernel@gmail.com are > > origin.patch > linux-next.patch > mm-remove-find_max_pfn_with_active_regions.patch > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 9:16 ` + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree Mel Gorman @ 2008-07-28 11:15 ` Yinghai Lu 2008-07-28 11:38 ` Mel Gorman 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-07-28 11:15 UTC (permalink / raw) To: Mel Gorman; +Cc: akpm, linux-mm On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: >> >> The patch titled >> mm: remove find_max_pfn_with_active_regions >> has been added to the -mm tree. Its filename is >> mm-remove-find_max_pfn_with_active_regions.patch >> >> Before you just go and hit "reply", please: >> a) Consider who else should be cc'ed >> b) Prefer to cc a suitable mailing list as well >> c) Ideally: find the original patch on the mailing list and do a >> reply-to-all to that, adding suitable additional cc's >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find >> out what to do about this >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ >> >> ------------------------------------------------------ >> Subject: mm: remove find_max_pfn_with_active_regions >> From: Yinghai Lu <yhlu.kernel@gmail.com> >> >> It has no user now >> >> Also print out info about adding/removing active regions. >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> >> Cc: Mel Gorman <mel@csn.ul.ie> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> --- >> >> include/linux/mm.h | 1 - >> mm/page_alloc.c | 22 ++-------------------- >> 2 files changed, 2 insertions(+), 21 deletions(-) >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions >> +++ a/include/linux/mm.h >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran >> extern void get_pfn_range_for_nid(unsigned int nid, >> unsigned long *start_pfn, unsigned long *end_pfn); >> extern unsigned long find_min_pfn_with_active_regions(void); >> -extern unsigned long find_max_pfn_with_active_regions(void); >> extern void free_bootmem_with_active_regions(int nid, >> unsigned long max_low_pfn); >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions >> +++ a/mm/page_alloc.c >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in >> { >> int i; >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", >> - "Entering add_active_range(%d, %#lx, %#lx) " >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " >> "%d entries of %d used\n", >> nid, start_pfn, end_pfn, >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); > > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On > some machines, this will be very noisy. For example, some POWER configurations > will print out one line for every 16MB of memory with this patch. I don't know, on x86 esp the first node, that is some informative. or change that back to printk(KERN_DEBUG) ? hope the user put debug on command_line to get enough info. otherwise without "mminit_loglevel=" will get that debug info. > >> @@ -3635,7 +3634,7 @@ void __init remove_active_range(unsigned >> int i, j; >> int removed = 0; >> >> - printk(KERN_DEBUG "remove_active_range (%d, %lu, %lu)\n", >> + printk(KERN_INFO "Removing active range (%d, %#lx, %#lx)\n", >> nid, start_pfn, end_pfn); >> > > This call is a lot rarer but I still don't see why it is being moved to > KERN_INFO. If anything, that should have been another mminit_printk() call > and one I obviously missed. use by 32bit x86 only. YH -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 11:15 ` Yinghai Lu @ 2008-07-28 11:38 ` Mel Gorman 2008-07-28 18:25 ` Yinghai Lu 0 siblings, 1 reply; 12+ messages in thread From: Mel Gorman @ 2008-07-28 11:38 UTC (permalink / raw) To: Yinghai Lu; +Cc: akpm, linux-mm On (28/07/08 04:15), Yinghai Lu didst pronounce: > On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: > > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: > >> > >> The patch titled > >> mm: remove find_max_pfn_with_active_regions > >> has been added to the -mm tree. Its filename is > >> mm-remove-find_max_pfn_with_active_regions.patch > >> > >> Before you just go and hit "reply", please: > >> a) Consider who else should be cc'ed > >> b) Prefer to cc a suitable mailing list as well > >> c) Ideally: find the original patch on the mailing list and do a > >> reply-to-all to that, adding suitable additional cc's > >> > >> *** Remember to use Documentation/SubmitChecklist when testing your code *** > >> > >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > >> out what to do about this > >> > >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ > >> > >> ------------------------------------------------------ > >> Subject: mm: remove find_max_pfn_with_active_regions > >> From: Yinghai Lu <yhlu.kernel@gmail.com> > >> > >> It has no user now > >> > >> Also print out info about adding/removing active regions. > >> > >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > >> Cc: Mel Gorman <mel@csn.ul.ie> > >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > >> --- > >> > >> include/linux/mm.h | 1 - > >> mm/page_alloc.c | 22 ++-------------------- > >> 2 files changed, 2 insertions(+), 21 deletions(-) > >> > >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h > >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions > >> +++ a/include/linux/mm.h > >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran > >> extern void get_pfn_range_for_nid(unsigned int nid, > >> unsigned long *start_pfn, unsigned long *end_pfn); > >> extern unsigned long find_min_pfn_with_active_regions(void); > >> -extern unsigned long find_max_pfn_with_active_regions(void); > >> extern void free_bootmem_with_active_regions(int nid, > >> unsigned long max_low_pfn); > >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); > >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c > >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions > >> +++ a/mm/page_alloc.c > >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in > >> { > >> int i; > >> > >> - mminit_dprintk(MMINIT_TRACE, "memory_register", > >> - "Entering add_active_range(%d, %#lx, %#lx) " > >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " > >> "%d entries of %d used\n", > >> nid, start_pfn, end_pfn, > >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); > > > > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On > > some machines, this will be very noisy. For example, some POWER configurations > > will print out one line for every 16MB of memory with this patch. > > I don't know, on x86 esp the first node, that is some informative. > or change that back to printk(KERN_DEBUG) ? > > hope the user put debug on command_line to get enough info. > > otherwise without "mminit_loglevel=" will get that debug info. > It's the type of information that is only useful when debugging memory initialisation problems. The more friendly information can be found at the lines starting with early_node_map[1] active PFN ranges and this is already logged. The fact that mminit_loglevel needs loglevel needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= parameter. I still am not convinced that these needs to be logged at KERN_INFO level. > > > >> @@ -3635,7 +3634,7 @@ void __init remove_active_range(unsigned > >> int i, j; > >> int removed = 0; > >> > >> - printk(KERN_DEBUG "remove_active_range (%d, %lu, %lu)\n", > >> + printk(KERN_INFO "Removing active range (%d, %#lx, %#lx)\n", > >> nid, start_pfn, end_pfn); > >> > > > > This call is a lot rarer but I still don't see why it is being moved to > > KERN_INFO. If anything, that should have been another mminit_printk() call > > and one I obviously missed. > use by 32bit x86 only. > > YH > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 11:38 ` Mel Gorman @ 2008-07-28 18:25 ` Yinghai Lu 2008-07-28 19:15 ` Mel Gorman 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-07-28 18:25 UTC (permalink / raw) To: Mel Gorman; +Cc: akpm, linux-mm On Mon, Jul 28, 2008 at 4:38 AM, Mel Gorman <mel@csn.ul.ie> wrote: > On (28/07/08 04:15), Yinghai Lu didst pronounce: >> On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: >> > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: >> >> >> >> The patch titled >> >> mm: remove find_max_pfn_with_active_regions >> >> has been added to the -mm tree. Its filename is >> >> mm-remove-find_max_pfn_with_active_regions.patch >> >> >> >> Before you just go and hit "reply", please: >> >> a) Consider who else should be cc'ed >> >> b) Prefer to cc a suitable mailing list as well >> >> c) Ideally: find the original patch on the mailing list and do a >> >> reply-to-all to that, adding suitable additional cc's >> >> >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** >> >> >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find >> >> out what to do about this >> >> >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ >> >> >> >> ------------------------------------------------------ >> >> Subject: mm: remove find_max_pfn_with_active_regions >> >> From: Yinghai Lu <yhlu.kernel@gmail.com> >> >> >> >> It has no user now >> >> >> >> Also print out info about adding/removing active regions. >> >> >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> >> >> Cc: Mel Gorman <mel@csn.ul.ie> >> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> >> --- >> >> >> >> include/linux/mm.h | 1 - >> >> mm/page_alloc.c | 22 ++-------------------- >> >> 2 files changed, 2 insertions(+), 21 deletions(-) >> >> >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h >> >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions >> >> +++ a/include/linux/mm.h >> >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran >> >> extern void get_pfn_range_for_nid(unsigned int nid, >> >> unsigned long *start_pfn, unsigned long *end_pfn); >> >> extern unsigned long find_min_pfn_with_active_regions(void); >> >> -extern unsigned long find_max_pfn_with_active_regions(void); >> >> extern void free_bootmem_with_active_regions(int nid, >> >> unsigned long max_low_pfn); >> >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); >> >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c >> >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions >> >> +++ a/mm/page_alloc.c >> >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in >> >> { >> >> int i; >> >> >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", >> >> - "Entering add_active_range(%d, %#lx, %#lx) " >> >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " >> >> "%d entries of %d used\n", >> >> nid, start_pfn, end_pfn, >> >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); >> > >> > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On >> > some machines, this will be very noisy. For example, some POWER configurations >> > will print out one line for every 16MB of memory with this patch. >> >> I don't know, on x86 esp the first node, that is some informative. >> or change that back to printk(KERN_DEBUG) ? >> >> hope the user put debug on command_line to get enough info. >> >> otherwise without "mminit_loglevel=" will get that debug info. >> > > It's the type of information that is only useful when debugging memory > initialisation problems. The more friendly information can be found at > the lines starting with > > early_node_map[1] active PFN ranges > > and this is already logged. The fact that mminit_loglevel needs loglevel > needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= > parameter. I still am not convinced that these needs to be logged at > KERN_INFO level. I hope: when ask user to append "debug" we can get enough debug info without other extra ... and then if want add-on spew info, could ask them to append initcall_debug, mminit_debug. current "mminit_loglevel is default to 0 " doesn't look reasonable, it hide some info when we could get if append "debug" only that we got for years. YH -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 18:25 ` Yinghai Lu @ 2008-07-28 19:15 ` Mel Gorman 2008-07-28 19:38 ` Yinghai Lu 0 siblings, 1 reply; 12+ messages in thread From: Mel Gorman @ 2008-07-28 19:15 UTC (permalink / raw) To: Yinghai Lu; +Cc: akpm, linux-mm On (28/07/08 11:25), Yinghai Lu didst pronounce: > On Mon, Jul 28, 2008 at 4:38 AM, Mel Gorman <mel@csn.ul.ie> wrote: > > On (28/07/08 04:15), Yinghai Lu didst pronounce: > >> On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: > >> > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: > >> >> > >> >> The patch titled > >> >> mm: remove find_max_pfn_with_active_regions > >> >> has been added to the -mm tree. Its filename is > >> >> mm-remove-find_max_pfn_with_active_regions.patch > >> >> > >> >> Before you just go and hit "reply", please: > >> >> a) Consider who else should be cc'ed > >> >> b) Prefer to cc a suitable mailing list as well > >> >> c) Ideally: find the original patch on the mailing list and do a > >> >> reply-to-all to that, adding suitable additional cc's > >> >> > >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** > >> >> > >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > >> >> out what to do about this > >> >> > >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ > >> >> > >> >> ------------------------------------------------------ > >> >> Subject: mm: remove find_max_pfn_with_active_regions > >> >> From: Yinghai Lu <yhlu.kernel@gmail.com> > >> >> > >> >> It has no user now > >> >> > >> >> Also print out info about adding/removing active regions. > >> >> > >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > >> >> Cc: Mel Gorman <mel@csn.ul.ie> > >> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > >> >> --- > >> >> > >> >> include/linux/mm.h | 1 - > >> >> mm/page_alloc.c | 22 ++-------------------- > >> >> 2 files changed, 2 insertions(+), 21 deletions(-) > >> >> > >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h > >> >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions > >> >> +++ a/include/linux/mm.h > >> >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran > >> >> extern void get_pfn_range_for_nid(unsigned int nid, > >> >> unsigned long *start_pfn, unsigned long *end_pfn); > >> >> extern unsigned long find_min_pfn_with_active_regions(void); > >> >> -extern unsigned long find_max_pfn_with_active_regions(void); > >> >> extern void free_bootmem_with_active_regions(int nid, > >> >> unsigned long max_low_pfn); > >> >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); > >> >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c > >> >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions > >> >> +++ a/mm/page_alloc.c > >> >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in > >> >> { > >> >> int i; > >> >> > >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", > >> >> - "Entering add_active_range(%d, %#lx, %#lx) " > >> >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " > >> >> "%d entries of %d used\n", > >> >> nid, start_pfn, end_pfn, > >> >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); > >> > > >> > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On > >> > some machines, this will be very noisy. For example, some POWER configurations > >> > will print out one line for every 16MB of memory with this patch. > >> > >> I don't know, on x86 esp the first node, that is some informative. > >> or change that back to printk(KERN_DEBUG) ? > >> > >> hope the user put debug on command_line to get enough info. > >> > >> otherwise without "mminit_loglevel=" will get that debug info. > >> > > > > It's the type of information that is only useful when debugging memory > > initialisation problems. The more friendly information can be found at > > the lines starting with > > > > early_node_map[1] active PFN ranges > > > > and this is already logged. The fact that mminit_loglevel needs loglevel > > needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= > > parameter. I still am not convinced that these needs to be logged at > > KERN_INFO level. > > I hope: when ask user to append "debug" we can get enough debug info > without other extra ... > I disagree. The memory init output is very verbose, which is why the mminit_debug framework was made quiet by default. In the event it is useful, it is because memory initialisation broken and at that point, it's simple enough to request the user to add the necessary options. It shouldn't be visible by default. This is similar in principal to acpi.debug_level for example. Perhaps we are going about this the wrong way, why do you want it to be visible so easily? My expectation is that the information is only useful when memory inialisation is failing but maybe you have another use in mind. > and then if want add-on spew info, could ask them to append > initcall_debug, mminit_debug. > > current "mminit_loglevel is default to 0 " doesn't look reasonable, it > hide some info when we could get if append "debug" only that we got > for years. > Not years, this information being available at all is relatively recent. Arch-independent zone sizing (that prints this) is only there since 2.6.24 I think. There are also other subsystems (like ACPI) that only output more debug information when specifically requested. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 19:15 ` Mel Gorman @ 2008-07-28 19:38 ` Yinghai Lu 2008-07-28 20:00 ` Mel Gorman 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-07-28 19:38 UTC (permalink / raw) To: Mel Gorman; +Cc: akpm, linux-mm On Mon, Jul 28, 2008 at 12:15 PM, Mel Gorman <mel@csn.ul.ie> wrote: > On (28/07/08 11:25), Yinghai Lu didst pronounce: >> On Mon, Jul 28, 2008 at 4:38 AM, Mel Gorman <mel@csn.ul.ie> wrote: >> > On (28/07/08 04:15), Yinghai Lu didst pronounce: >> >> On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: >> >> > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: >> >> >> >> >> >> The patch titled >> >> >> mm: remove find_max_pfn_with_active_regions >> >> >> has been added to the -mm tree. Its filename is >> >> >> mm-remove-find_max_pfn_with_active_regions.patch >> >> >> >> >> >> Before you just go and hit "reply", please: >> >> >> a) Consider who else should be cc'ed >> >> >> b) Prefer to cc a suitable mailing list as well >> >> >> c) Ideally: find the original patch on the mailing list and do a >> >> >> reply-to-all to that, adding suitable additional cc's >> >> >> >> >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** >> >> >> >> >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find >> >> >> out what to do about this >> >> >> >> >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ >> >> >> >> >> >> ------------------------------------------------------ >> >> >> Subject: mm: remove find_max_pfn_with_active_regions >> >> >> From: Yinghai Lu <yhlu.kernel@gmail.com> >> >> >> >> >> >> It has no user now >> >> >> >> >> >> Also print out info about adding/removing active regions. >> >> >> >> >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> >> >> >> Cc: Mel Gorman <mel@csn.ul.ie> >> >> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> >> >> --- >> >> >> >> >> >> include/linux/mm.h | 1 - >> >> >> mm/page_alloc.c | 22 ++-------------------- >> >> >> 2 files changed, 2 insertions(+), 21 deletions(-) >> >> >> >> >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h >> >> >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions >> >> >> +++ a/include/linux/mm.h >> >> >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran >> >> >> extern void get_pfn_range_for_nid(unsigned int nid, >> >> >> unsigned long *start_pfn, unsigned long *end_pfn); >> >> >> extern unsigned long find_min_pfn_with_active_regions(void); >> >> >> -extern unsigned long find_max_pfn_with_active_regions(void); >> >> >> extern void free_bootmem_with_active_regions(int nid, >> >> >> unsigned long max_low_pfn); >> >> >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); >> >> >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c >> >> >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions >> >> >> +++ a/mm/page_alloc.c >> >> >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in >> >> >> { >> >> >> int i; >> >> >> >> >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", >> >> >> - "Entering add_active_range(%d, %#lx, %#lx) " >> >> >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " >> >> >> "%d entries of %d used\n", >> >> >> nid, start_pfn, end_pfn, >> >> >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); >> >> > >> >> > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On >> >> > some machines, this will be very noisy. For example, some POWER configurations >> >> > will print out one line for every 16MB of memory with this patch. >> >> >> >> I don't know, on x86 esp the first node, that is some informative. >> >> or change that back to printk(KERN_DEBUG) ? >> >> >> >> hope the user put debug on command_line to get enough info. >> >> >> >> otherwise without "mminit_loglevel=" will get that debug info. >> >> >> > >> > It's the type of information that is only useful when debugging memory >> > initialisation problems. The more friendly information can be found at >> > the lines starting with >> > >> > early_node_map[1] active PFN ranges >> > >> > and this is already logged. The fact that mminit_loglevel needs loglevel >> > needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= >> > parameter. I still am not convinced that these needs to be logged at >> > KERN_INFO level. >> >> I hope: when ask user to append "debug" we can get enough debug info >> without other extra ... >> > > I disagree. The memory init output is very verbose, which is why the > mminit_debug framework was made quiet by default. In the event it is useful, > it is because memory initialisation broken and at that point, it's simple > enough to request the user to add the necessary options. It shouldn't be > visible by default. This is similar in principal to acpi.debug_level for > example. not that verbose, on my 8 sockets system LBSuse:/x/kernel.org # ./kexec -e Starting new kernel Initializing cgroup subsys cpuset Linux version 2.6.26-tip-01876-g0609af7-dirty (yhlu@linux-zpir) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #509 SMP Sun Jul 27 17:47:45 PDT 2008 Command line: apic=verbose show_msr=1 debug mminit_loglevel=4 initcall_debug pci=routeirq lpfc.lpfc_use_msi=1 ramdisk_size=131072 root=/dev/ram0 rw ip=dhcp console=uart8250,io,0x3f8,115200n8 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided physical RAM map: BIOS-e820: 0000000000000100 - 0000000000095800 (usable) BIOS-e820: 0000000000095800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable) BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved) BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data) BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS) BIOS-e820: 00000000d7ff0000 - 00000000d8000000 (reserved) BIOS-e820: 00000000dc000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000004028000000 (usable) Early serial console at I/O port 0x3f8 (options '115200n8') console [uart0] enabled last_pfn = 0x4028000 max_arch_pfn = 0x3ffffffff x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 last_pfn = 0xd7fa0 max_arch_pfn = 0x3ffffffff init_memory_mapping Using GB pages for direct mapping 0000000000 - 00c0000000 page 1G 00c0000000 - 00d7e00000 page 2M 00d7e00000 - 00d7fa0000 page 4k kernel direct mapping tables up to d7fa0000 @ 8000-b000 last_map_addr: d7fa0000 end: d7fa0000 init_memory_mapping Using GB pages for direct mapping 0100000000 - 4000000000 page 1G 4000000000 - 4028000000 page 2M kernel direct mapping tables up to 4028000000 @ a000-c000 last_map_addr: 4028000000 end: 4028000000 RAMDISK: 7e6cb000 - 7fff3e0b DMI present. ACPI: RSDP 000F99A0, 0024 (r2 SUN ) ACPI: XSDT D7FB0100, 009C (r1 SUN X4600 M2 98 MSFT 97) ACPI: FACP D7FB0290, 00F4 (r3 SUN X4600 M2 98 MSFT 97) ACPI: DSDT D7FB0710, 718F (r1 SUN X4600 M2 98 INTL 20051117) ACPI: FACS D7FBE000, 0040 ACPI: APIC D7FB0390, 0170 (r1 SUN X4600 M2 98 MSFT 97) ACPI: SPCR D7FB0500, 0050 (r1 SUN X4600 M2 98 MSFT 97) ACPI: MCFG D7FB0550, 003C (r1 SUN X4600 M2 98 MSFT 97) ACPI: SLIT D7FB064C, 006C (r1 SUN X4600 M2 98 MSFT 97) ACPI: SPMI D7FB06C0, 0041 (r5 SUN OEMSPMI 98 MSFT 97) ACPI: OEMB D7FBE040, 0063 (r1 SUN X4600 M2 98 MSFT 97) ACPI: SRAT D7FB78A0, 03C0 (r1 AMD HAMMER 1 AMD 1) ACPI: HPET D7FB7C60, 0038 (r1 SUN X4600 M2 98 MSFT 97) ACPI: IPET D7FB7CA0, 0038 (r1 SUN X4600 M2 98 MSFT 97) ACPI: EINJ D7FB7CE0, 0130 (r1 AMIER AMI_EINJ 7000808 MSFT 97) ACPI: BERT D7FB7E70, 0030 (r1 AMIER AMI_BERT 7000808 MSFT 97) ACPI: ERST D7FB7EA0, 01B0 (r1 AMIER AMI_ERST 7000808 MSFT 97) ACPI: HEST D7FB8050, 00A8 (r1 AMIER AMI_HEST 7000808 MSFT 97) ACPI: SSDT D7FB8100, 5084 (r1 A M I POWERNOW 1 AMD 1) SRAT: PXM 0 -> APIC 4 -> Node 0 SRAT: PXM 0 -> APIC 5 -> Node 0 SRAT: PXM 0 -> APIC 6 -> Node 0 SRAT: PXM 0 -> APIC 7 -> Node 0 SRAT: PXM 1 -> APIC 8 -> Node 1 SRAT: PXM 1 -> APIC 9 -> Node 1 SRAT: PXM 1 -> APIC 10 -> Node 1 SRAT: PXM 1 -> APIC 11 -> Node 1 SRAT: PXM 2 -> APIC 12 -> Node 2 SRAT: PXM 2 -> APIC 13 -> Node 2 SRAT: PXM 2 -> APIC 14 -> Node 2 SRAT: PXM 2 -> APIC 15 -> Node 2 SRAT: PXM 3 -> APIC 16 -> Node 3 SRAT: PXM 3 -> APIC 17 -> Node 3 SRAT: PXM 3 -> APIC 18 -> Node 3 SRAT: PXM 3 -> APIC 19 -> Node 3 SRAT: PXM 4 -> APIC 20 -> Node 4 SRAT: PXM 4 -> APIC 21 -> Node 4 SRAT: PXM 4 -> APIC 22 -> Node 4 SRAT: PXM 4 -> APIC 23 -> Node 4 SRAT: PXM 5 -> APIC 24 -> Node 5 SRAT: PXM 5 -> APIC 25 -> Node 5 SRAT: PXM 5 -> APIC 26 -> Node 5 SRAT: PXM 5 -> APIC 27 -> Node 5 SRAT: PXM 6 -> APIC 28 -> Node 6 SRAT: PXM 6 -> APIC 29 -> Node 6 SRAT: PXM 6 -> APIC 30 -> Node 6 SRAT: PXM 6 -> APIC 31 -> Node 6 SRAT: PXM 7 -> APIC 32 -> Node 7 SRAT: PXM 7 -> APIC 33 -> Node 7 SRAT: PXM 7 -> APIC 34 -> Node 7 SRAT: PXM 7 -> APIC 35 -> Node 7 SRAT: Node 0 PXM 0 0-a0000 Adding active range (0, 0x1, 0x95) 0 entries of 3200 used ======> hope to see the difference with mminit_loglevel=4 SRAT: Node 0 PXM 0 100000-d8000000 Adding active range (0, 0x100, 0xd7fa0) 1 entries of 3200 used ======> hope to see the difference with mminit_loglevel=4 SRAT: Node 0 PXM 0 100000000-828000000 Adding active range (0, 0x100000, 0x828000) 2 entries of 3200 used SRAT: Node 1 PXM 1 828000000-1028000000 Adding active range (1, 0x828000, 0x1028000) 3 entries of 3200 used SRAT: Node 2 PXM 2 1028000000-1828000000 Adding active range (2, 0x1028000, 0x1828000) 4 entries of 3200 used SRAT: Node 3 PXM 3 1828000000-2028000000 Adding active range (3, 0x1828000, 0x2028000) 5 entries of 3200 used SRAT: Node 4 PXM 4 2028000000-2828000000 Adding active range (4, 0x2028000, 0x2828000) 6 entries of 3200 used SRAT: Node 5 PXM 5 2828000000-3028000000 Adding active range (5, 0x2828000, 0x3028000) 7 entries of 3200 used SRAT: Node 6 PXM 6 3028000000-3828000000 Adding active range (6, 0x3028000, 0x3828000) 8 entries of 3200 used SRAT: Node 7 PXM 7 3828000000-4028000000 Adding active range (7, 0x3828000, 0x4028000) 9 entries of 3200 used ACPI: SLIT: nodes = 8 10 12 12 14 14 14 14 16 12 10 14 12 14 14 12 14 12 14 10 14 12 12 14 14 14 12 14 10 12 12 14 14 14 14 12 12 10 14 12 14 14 14 12 12 14 10 14 12 14 12 14 14 12 14 10 12 16 14 14 14 14 12 12 10 NUMA: Allocated memnodemap from b000 - 8b580 NUMA: Using 20 for the hash shift. Bootmem setup node 0 0000000000000000-0000000828000000 NODE_DATA [000000000008b580 - 000000000009057f] bootmap [0000000001078000 - 000000000117cfff] pages 105 (9 early reservations) ==> bootmem [0000000000 - 0828000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] #2 [0000200000 - 0001077c64] TEXT DATA BSS ==> [0000200000 - 0001077c64] #3 [007e6cb000 - 007fff3e0b] RAMDISK ==> [007e6cb000 - 007fff3e0b] #4 [0000095400 - 0000100000] BIOS reserved ==> [0000095400 - 0000100000] #5 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000] #6 [000000a000 - 000000b000] PGTABLE ==> [000000a000 - 000000b000] #7 [0000001000 - 000000106c] ACPI SLIT ==> [0000001000 - 000000106c] #8 [000000b000 - 000008b580] MEMNODEMAP ==> [000000b000 - 000008b580] Bootmem setup node 1 0000000828000000-0000001028000000 NODE_DATA [0000000828000000 - 0000000828004fff] bootmap [0000000828005000 - 0000000828104fff] pages 100 ... Scan SMP from ffff880000000000 for 1024 bytes. Scan SMP from ffff88000009fc00 for 1024 bytes. Scan SMP from ffff8800000f0000 for 65536 bytes. found SMP MP-table at [ffff8800000ff780] 000ff780 [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88002810e000 on node 0 [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88002810f000 on node 0 [ffffe2001c8c0000-ffffe2001c9fffff] potential offnode page_structs [ffffe20000000000-ffffe2001c9fffff] PMD -> [ffff880028200000-ffff8800443fffff] on node 0 [ffffe200388c0000-ffffe200389fffff] potential offnode page_structs [ffffe2001ca00000-ffffe200389fffff] PMD -> [ffff880828200000-ffff8808441fffff] on node 1 [ffffe20040000000-ffffe2007fffffff] PUD ->ffff88102f800000 on node 2 [ffffe20038a00000-ffffe2003fffffff] PMD -> [ffff881028200000-ffff88102f7fffff] on node 2 [ffffe200548c0000-ffffe200549fffff] potential offnode page_structs [ffffe20040000000-ffffe200549fffff] PMD -> [ffff88102fa00000-ffff8810443fffff] on node 2 [ffffe200708c0000-ffffe200709fffff] potential offnode page_structs [ffffe20054a00000-ffffe200709fffff] PMD -> [ffff881828200000-ffff8818441fffff] on node 3 [ffffe20080000000-ffffe200bfffffff] PUD ->ffff882037800000 on node 4 [ffffe20070a00000-ffffe2007fffffff] PMD -> [ffff882028200000-ffff8820377fffff] on node 4 [ffffe2008c8c0000-ffffe2008c9fffff] potential offnode page_structs [ffffe20080000000-ffffe2008c9fffff] PMD -> [ffff882037a00000-ffff8820443fffff] on node 4 [ffffe200a88c0000-ffffe200a89fffff] potential offnode page_structs [ffffe2008ca00000-ffffe200a89fffff] PMD -> [ffff882828200000-ffff8828441fffff] on node 5 [ffffe200c0000000-ffffe200ffffffff] PUD ->ffff88303f800000 on node 6 [ffffe200a8a00000-ffffe200bfffffff] PMD -> [ffff883028200000-ffff88303f7fffff] on node 6 [ffffe200c48c0000-ffffe200c49fffff] potential offnode page_structs [ffffe200c0000000-ffffe200c49fffff] PMD -> [ffff88303fa00000-ffff8830443fffff] on node 6 [ffffe200c4a00000-ffffe200e09fffff] PMD -> [ffff883828200000-ffff8838441fffff] on node 7 Zone PFN ranges: DMA 0x00000001 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x04028000 Movable zone start PFN for each node early_node_map[10] active PFN ranges 0: 0x00000001 -> 0x00000095 0: 0x00000100 -> 0x000d7fa0 0: 0x00100000 -> 0x00828000 1: 0x00828000 -> 0x01028000 2: 0x01028000 -> 0x01828000 3: 0x01828000 -> 0x02028000 4: 0x02028000 -> 0x02828000 5: 0x02828000 -> 0x03028000 6: 0x03028000 -> 0x03828000 7: 0x03828000 -> 0x04028000 mminit::pageflags_layout_widths Section 0 Node 6 Zone 2 Flags 19 mminit::pageflags_layout_shifts Section 17 Node 6 Zone 2 mminit::pageflags_layout_offsets Section 0 Node 58 Zone 56 mminit::pageflags_layout_zoneid Zone ID: 56 -> 64 mminit::pageflags_layout_usage location: 64 -> 56 unused 56 -> 19 flags 19 -> 0 On node 0 totalpages: 8388404 mminit::memmap_init DMA zone: 56 pages used for memmap mminit::memmap_init DMA zone: 242 pages reserved =====> hope to see the memmap pages used here with mminit_loglevel DMA zone: 3690 pages, LIFO batch:0 mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096 mminit::memmap_init DMA32 zone: 14280 pages used for memmap DMA32 zone: 866264 pages, LIFO batch:31 mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576 mminit::memmap_init Normal zone: 102592 pages used for memmap Normal zone: 7401280 pages, LIFO batch:31 mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 8552448 mminit::memmap_init Movable zone: 0 pages used for memmap On node 1 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 1 zone 2 pfns 8552448 -> 16941056 mminit::memmap_init Movable zone: 0 pages used for memmap On node 2 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 2 zone 2 pfns 16941056 -> 25329664 mminit::memmap_init Movable zone: 0 pages used for memmap On node 3 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 3 zone 2 pfns 25329664 -> 33718272 mminit::memmap_init Movable zone: 0 pages used for memmap On node 4 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 4 zone 2 pfns 33718272 -> 42106880 mminit::memmap_init Movable zone: 0 pages used for memmap On node 5 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 5 zone 2 pfns 42106880 -> 50495488 mminit::memmap_init Movable zone: 0 pages used for memmap On node 6 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 6 zone 2 pfns 50495488 -> 58884096 mminit::memmap_init Movable zone: 0 pages used for memmap On node 7 totalpages: 8388608 mminit::memmap_init DMA zone: 0 pages used for memmap mminit::memmap_init DMA32 zone: 0 pages used for memmap mminit::memmap_init Normal zone: 114688 pages used for memmap Normal zone: 8273920 pages, LIFO batch:31 mminit::memmap_init Initialising map node 7 zone 2 pfns 58884096 -> 67272704 mminit::memmap_init Movable zone: 0 pages used for memmap BTW, please check if mminit_loglevel=3 and mminit_loglevel=4 is the same? suggest to switch to mminit_debug, and that will be used in addition to "debug" to print out spew info for ... YH -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 19:38 ` Yinghai Lu @ 2008-07-28 20:00 ` Mel Gorman 2008-07-28 20:14 ` Yinghai Lu 0 siblings, 1 reply; 12+ messages in thread From: Mel Gorman @ 2008-07-28 20:00 UTC (permalink / raw) To: Yinghai Lu; +Cc: akpm, linux-mm On (28/07/08 12:38), Yinghai Lu didst pronounce: > On Mon, Jul 28, 2008 at 12:15 PM, Mel Gorman <mel@csn.ul.ie> wrote: > > On (28/07/08 11:25), Yinghai Lu didst pronounce: > >> On Mon, Jul 28, 2008 at 4:38 AM, Mel Gorman <mel@csn.ul.ie> wrote: > >> > On (28/07/08 04:15), Yinghai Lu didst pronounce: > >> >> On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: > >> >> > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: > >> >> >> > >> >> >> The patch titled > >> >> >> mm: remove find_max_pfn_with_active_regions > >> >> >> has been added to the -mm tree. Its filename is > >> >> >> mm-remove-find_max_pfn_with_active_regions.patch > >> >> >> > >> >> >> Before you just go and hit "reply", please: > >> >> >> a) Consider who else should be cc'ed > >> >> >> b) Prefer to cc a suitable mailing list as well > >> >> >> c) Ideally: find the original patch on the mailing list and do a > >> >> >> reply-to-all to that, adding suitable additional cc's > >> >> >> > >> >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** > >> >> >> > >> >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > >> >> >> out what to do about this > >> >> >> > >> >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ > >> >> >> > >> >> >> ------------------------------------------------------ > >> >> >> Subject: mm: remove find_max_pfn_with_active_regions > >> >> >> From: Yinghai Lu <yhlu.kernel@gmail.com> > >> >> >> > >> >> >> It has no user now > >> >> >> > >> >> >> Also print out info about adding/removing active regions. > >> >> >> > >> >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > >> >> >> Cc: Mel Gorman <mel@csn.ul.ie> > >> >> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > >> >> >> --- > >> >> >> > >> >> >> include/linux/mm.h | 1 - > >> >> >> mm/page_alloc.c | 22 ++-------------------- > >> >> >> 2 files changed, 2 insertions(+), 21 deletions(-) > >> >> >> > >> >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h > >> >> >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions > >> >> >> +++ a/include/linux/mm.h > >> >> >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran > >> >> >> extern void get_pfn_range_for_nid(unsigned int nid, > >> >> >> unsigned long *start_pfn, unsigned long *end_pfn); > >> >> >> extern unsigned long find_min_pfn_with_active_regions(void); > >> >> >> -extern unsigned long find_max_pfn_with_active_regions(void); > >> >> >> extern void free_bootmem_with_active_regions(int nid, > >> >> >> unsigned long max_low_pfn); > >> >> >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); > >> >> >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c > >> >> >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions > >> >> >> +++ a/mm/page_alloc.c > >> >> >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in > >> >> >> { > >> >> >> int i; > >> >> >> > >> >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", > >> >> >> - "Entering add_active_range(%d, %#lx, %#lx) " > >> >> >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " > >> >> >> "%d entries of %d used\n", > >> >> >> nid, start_pfn, end_pfn, > >> >> >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); > >> >> > > >> >> > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On > >> >> > some machines, this will be very noisy. For example, some POWER configurations > >> >> > will print out one line for every 16MB of memory with this patch. > >> >> > >> >> I don't know, on x86 esp the first node, that is some informative. > >> >> or change that back to printk(KERN_DEBUG) ? > >> >> > >> >> hope the user put debug on command_line to get enough info. > >> >> > >> >> otherwise without "mminit_loglevel=" will get that debug info. > >> >> > >> > > >> > It's the type of information that is only useful when debugging memory > >> > initialisation problems. The more friendly information can be found at > >> > the lines starting with > >> > > >> > early_node_map[1] active PFN ranges > >> > > >> > and this is already logged. The fact that mminit_loglevel needs loglevel > >> > needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= > >> > parameter. I still am not convinced that these needs to be logged at > >> > KERN_INFO level. > >> > >> I hope: when ask user to append "debug" we can get enough debug info > >> without other extra ... > >> > > > > I disagree. The memory init output is very verbose, which is why the > > mminit_debug framework was made quiet by default. In the event it is useful, > > it is because memory initialisation broken and at that point, it's simple > > enough to request the user to add the necessary options. It shouldn't be > > visible by default. This is similar in principal to acpi.debug_level for > > example. > > not that verbose, on my 8 sockets system > Sure, on that system it's fine, but on others it is noisy. As I pointed out already, on certain PPC64 machines (all LPARS for example), this will output one line per 16MB of memory in the system which is excessive for a system that is booting correctly. On IA-64, it'll be at least 1 line per node which gets noisy. This http://lkml.org/lkml/2006/4/18/206 is a log of an IA-64 machine with an early version of arch-independent zone-sizing. See how it is outputting 4 lines per node on the system. > <dmesg log snipped> > I'm not sure what I'm meant to be getting from this log. Glancing through, it appeared to be printing out what was expected with the mminit_loglevel settings. > BTW, please check if mminit_loglevel=3 and mminit_loglevel=4 is the same? > Based on this definition, enum mminit_level { MMINIT_WARNING, MMINIT_VERIFY, MMINIT_TRACE }; I'd expect it to be the same. I guess the documentation should have said "3" and not "4" although it doesn't make much of a difference in terms of what the user gets with either value. > suggest to switch to mminit_debug, and that will be used in addition > to "debug" to print out spew info for ... > I'm not seeing what different a rename of the parameter will do. Even if the parameter was renamed, it does not mean current trace information during memory initialisation needs to be outputted as KERN_INFO which is what this patch is doing. I am still failing to understand why you want this information to be generally available. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 20:00 ` Mel Gorman @ 2008-07-28 20:14 ` Yinghai Lu 2008-07-28 20:40 ` Mel Gorman 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-07-28 20:14 UTC (permalink / raw) To: Mel Gorman; +Cc: akpm, linux-mm On Mon, Jul 28, 2008 at 1:00 PM, Mel Gorman <mel@csn.ul.ie> wrote: > On (28/07/08 12:38), Yinghai Lu didst pronounce: >> On Mon, Jul 28, 2008 at 12:15 PM, Mel Gorman <mel@csn.ul.ie> wrote: >> > On (28/07/08 11:25), Yinghai Lu didst pronounce: >> >> On Mon, Jul 28, 2008 at 4:38 AM, Mel Gorman <mel@csn.ul.ie> wrote: >> >> > On (28/07/08 04:15), Yinghai Lu didst pronounce: >> >> >> On Mon, Jul 28, 2008 at 2:16 AM, Mel Gorman <mel@csn.ul.ie> wrote: >> >> >> > On (27/07/08 20:13), akpm@linux-foundation.org didst pronounce: >> >> >> >> >> >> >> >> The patch titled >> >> >> >> mm: remove find_max_pfn_with_active_regions >> >> >> >> has been added to the -mm tree. Its filename is >> >> >> >> mm-remove-find_max_pfn_with_active_regions.patch >> >> >> >> >> >> >> >> Before you just go and hit "reply", please: >> >> >> >> a) Consider who else should be cc'ed >> >> >> >> b) Prefer to cc a suitable mailing list as well >> >> >> >> c) Ideally: find the original patch on the mailing list and do a >> >> >> >> reply-to-all to that, adding suitable additional cc's >> >> >> >> >> >> >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** >> >> >> >> >> >> >> >> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find >> >> >> >> out what to do about this >> >> >> >> >> >> >> >> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ >> >> >> >> >> >> >> >> ------------------------------------------------------ >> >> >> >> Subject: mm: remove find_max_pfn_with_active_regions >> >> >> >> From: Yinghai Lu <yhlu.kernel@gmail.com> >> >> >> >> >> >> >> >> It has no user now >> >> >> >> >> >> >> >> Also print out info about adding/removing active regions. >> >> >> >> >> >> >> >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> >> >> >> >> Cc: Mel Gorman <mel@csn.ul.ie> >> >> >> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> >> >> >> --- >> >> >> >> >> >> >> >> include/linux/mm.h | 1 - >> >> >> >> mm/page_alloc.c | 22 ++-------------------- >> >> >> >> 2 files changed, 2 insertions(+), 21 deletions(-) >> >> >> >> >> >> >> >> diff -puN include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions include/linux/mm.h >> >> >> >> --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions >> >> >> >> +++ a/include/linux/mm.h >> >> >> >> @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran >> >> >> >> extern void get_pfn_range_for_nid(unsigned int nid, >> >> >> >> unsigned long *start_pfn, unsigned long *end_pfn); >> >> >> >> extern unsigned long find_min_pfn_with_active_regions(void); >> >> >> >> -extern unsigned long find_max_pfn_with_active_regions(void); >> >> >> >> extern void free_bootmem_with_active_regions(int nid, >> >> >> >> unsigned long max_low_pfn); >> >> >> >> typedef int (*work_fn_t)(unsigned long, unsigned long, void *); >> >> >> >> diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c >> >> >> >> --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions >> >> >> >> +++ a/mm/page_alloc.c >> >> >> >> @@ -3572,8 +3572,7 @@ void __init add_active_range(unsigned in >> >> >> >> { >> >> >> >> int i; >> >> >> >> >> >> >> >> - mminit_dprintk(MMINIT_TRACE, "memory_register", >> >> >> >> - "Entering add_active_range(%d, %#lx, %#lx) " >> >> >> >> + printk(KERN_INFO "Adding active range (%d, %#lx, %#lx) " >> >> >> >> "%d entries of %d used\n", >> >> >> >> nid, start_pfn, end_pfn, >> >> >> >> nr_nodemap_entries, MAX_ACTIVE_REGIONS); >> >> >> > >> >> >> > Why are the mminit_dprintk() calls being converted to printk(KERN_INFO)? On >> >> >> > some machines, this will be very noisy. For example, some POWER configurations >> >> >> > will print out one line for every 16MB of memory with this patch. >> >> >> >> >> >> I don't know, on x86 esp the first node, that is some informative. >> >> >> or change that back to printk(KERN_DEBUG) ? >> >> >> >> >> >> hope the user put debug on command_line to get enough info. >> >> >> >> >> >> otherwise without "mminit_loglevel=" will get that debug info. >> >> >> >> >> > >> >> > It's the type of information that is only useful when debugging memory >> >> > initialisation problems. The more friendly information can be found at >> >> > the lines starting with >> >> > >> >> > early_node_map[1] active PFN ranges >> >> > >> >> > and this is already logged. The fact that mminit_loglevel needs loglevel >> >> > needs to be at KERN_DEBUG level is already documented for the mminit_loglevel= >> >> > parameter. I still am not convinced that these needs to be logged at >> >> > KERN_INFO level. >> >> >> >> I hope: when ask user to append "debug" we can get enough debug info >> >> without other extra ... >> >> >> > >> > I disagree. The memory init output is very verbose, which is why the >> > mminit_debug framework was made quiet by default. In the event it is useful, >> > it is because memory initialisation broken and at that point, it's simple >> > enough to request the user to add the necessary options. It shouldn't be >> > visible by default. This is similar in principal to acpi.debug_level for >> > example. >> >> not that verbose, on my 8 sockets system >> > > Sure, on that system it's fine, but on others it is noisy. As I pointed > out already, on certain PPC64 machines (all LPARS for example), this will > output one line per 16MB of memory in the system which is excessive for a > system that is booting correctly. On IA-64, it'll be at least 1 line per > node which gets noisy. This http://lkml.org/lkml/2006/4/18/206 is a log of > an IA-64 machine with an early version of arch-independent zone-sizing. See > how it is outputting 4 lines per node on the system. > >> <dmesg log snipped> >> > > I'm not sure what I'm meant to be getting from this log. Glancing through, > it appeared to be printing out what was expected with the mminit_loglevel > settings. > >> BTW, please check if mminit_loglevel=3 and mminit_loglevel=4 is the same? >> > > Based on this definition, > > enum mminit_level { > MMINIT_WARNING, > MMINIT_VERIFY, > MMINIT_TRACE > }; > > I'd expect it to be the same. I guess the documentation should have said > "3" and not "4" although it doesn't make much of a difference in terms of > what the user gets with either value. > >> suggest to switch to mminit_debug, and that will be used in addition >> to "debug" to print out spew info for ... >> > > I'm not seeing what different a rename of the parameter will do. Even if > the parameter was renamed, it does not mean current trace information during > memory initialisation needs to be outputted as KERN_INFO which is what this > patch is doing. I am still failing to understand why you want this information > to be generally available. how about KERN_DEBUG? please check Index: linux-2.6/mm/page_alloc.c =================================================================== --- linux-2.6.orig/mm/page_alloc.c +++ linux-2.6/mm/page_alloc.c @@ -3418,8 +3418,7 @@ static void __paginginit free_area_init_ PAGE_ALIGN(size * sizeof(struct page)) >> PAGE_SHIFT; if (realsize >= memmap_pages) { realsize -= memmap_pages; - mminit_dprintk(MMINIT_TRACE, "memmap_init", - "%s zone: %lu pages used for memmap\n", + printk(KERN_DEBUG "%s zone: %lu pages used for memmap\n", zone_names[j], memmap_pages); } else printk(KERN_WARNING @@ -3429,8 +3428,7 @@ static void __paginginit free_area_init_ /* Account for reserved pages */ if (j == 0 && realsize > dma_reserve) { realsize -= dma_reserve; - mminit_dprintk(MMINIT_TRACE, "memmap_init", - "%s zone: %lu pages reserved\n", + printk(KERN_DEBUG "%s zone: %lu pages reserved\n", zone_names[0], dma_reserve); } @@ -3572,8 +3570,7 @@ void __init add_active_range(unsigned in { int i; - mminit_dprintk(MMINIT_TRACE, "memory_register", - "Entering add_active_range(%d, %#lx, %#lx) " + printk(KERN_DEBUG "Adding active range (%d, %#lx, %#lx) " "%d entries of %d used\n", nid, start_pfn, end_pfn, nr_nodemap_entries, MAX_ACTIVE_REGIONS); @@ -3635,7 +3632,7 @@ void __init remove_active_range(unsigned int i, j; int removed = 0; - printk(KERN_DEBUG "remove_active_range (%d, %lu, %lu)\n", + printk(KERN_DEBUG "Removing active range (%d, %#lx, %#lx)\n", nid, start_pfn, end_pfn); /* Find the old active region end and shrink */ YH -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 20:14 ` Yinghai Lu @ 2008-07-28 20:40 ` Mel Gorman 2008-07-28 20:55 ` Andrew Morton 2008-07-28 21:24 ` Yinghai Lu 0 siblings, 2 replies; 12+ messages in thread From: Mel Gorman @ 2008-07-28 20:40 UTC (permalink / raw) To: Yinghai Lu; +Cc: akpm, linux-mm On (28/07/08 13:14), Yinghai Lu didst pronounce: > > <SNIP> > > > > I'm not seeing what different a rename of the parameter will do. Even if > > the parameter was renamed, it does not mean current trace information during > > memory initialisation needs to be outputted as KERN_INFO which is what this > > patch is doing. I am still failing to understand why you want this information > > to be generally available. > > how about KERN_DEBUG? > > please check > Still NAK due to the noise. Admittedly, I introduced the noise in the first place but it was complained about then as well. See http://lkml.org/lkml/2006/11/27/124 and later this http://lkml.org/lkml/2006/11/27/134 . At the risk of repeating myself, I am still failing to understand why you want this information to be generally available at any loglevel. My expectation is that the information is only of relevance when debugging memory initialisation problems in which case mminit_loglevel can be used. > Index: linux-2.6/mm/page_alloc.c > =================================================================== > --- linux-2.6.orig/mm/page_alloc.c > +++ linux-2.6/mm/page_alloc.c > @@ -3418,8 +3418,7 @@ static void __paginginit free_area_init_ > PAGE_ALIGN(size * sizeof(struct page)) >> PAGE_SHIFT; > if (realsize >= memmap_pages) { > realsize -= memmap_pages; > - mminit_dprintk(MMINIT_TRACE, "memmap_init", > - "%s zone: %lu pages used for memmap\n", > + printk(KERN_DEBUG "%s zone: %lu pages used for > memmap\n", > zone_names[j], memmap_pages); > } else > printk(KERN_WARNING > @@ -3429,8 +3428,7 @@ static void __paginginit free_area_init_ > /* Account for reserved pages */ > if (j == 0 && realsize > dma_reserve) { > realsize -= dma_reserve; > - mminit_dprintk(MMINIT_TRACE, "memmap_init", > - "%s zone: %lu pages reserved\n", > + printk(KERN_DEBUG "%s zone: %lu pages reserved\n", > zone_names[0], dma_reserve); > } > > @@ -3572,8 +3570,7 @@ void __init add_active_range(unsigned in > { > int i; > > - mminit_dprintk(MMINIT_TRACE, "memory_register", > - "Entering add_active_range(%d, %#lx, %#lx) " > + printk(KERN_DEBUG "Adding active range (%d, %#lx, %#lx) " > "%d entries of %d used\n", > nid, start_pfn, end_pfn, > nr_nodemap_entries, MAX_ACTIVE_REGIONS); > @@ -3635,7 +3632,7 @@ void __init remove_active_range(unsigned > int i, j; > int removed = 0; > > - printk(KERN_DEBUG "remove_active_range (%d, %lu, %lu)\n", > + printk(KERN_DEBUG "Removing active range (%d, %#lx, %#lx)\n", > nid, start_pfn, end_pfn); > > /* Find the old active region end and shrink */ > > > YH > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 20:40 ` Mel Gorman @ 2008-07-28 20:55 ` Andrew Morton 2008-07-28 21:16 ` Mel Gorman 2008-07-28 21:24 ` Yinghai Lu 1 sibling, 1 reply; 12+ messages in thread From: Andrew Morton @ 2008-07-28 20:55 UTC (permalink / raw) To: Mel Gorman; +Cc: yhlu.kernel, linux-mm On Mon, 28 Jul 2008 21:40:00 +0100 Mel Gorman <mel@csn.ul.ie> wrote: > > how about KERN_DEBUG? > > > > please check > > > > Still NAK due to the noise. blah. I changed the patch to this: --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions +++ a/include/linux/mm.h @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran extern void get_pfn_range_for_nid(unsigned int nid, unsigned long *start_pfn, unsigned long *end_pfn); extern unsigned long find_min_pfn_with_active_regions(void); -extern unsigned long find_max_pfn_with_active_regions(void); extern void free_bootmem_with_active_regions(int nid, unsigned long max_low_pfn); typedef int (*work_fn_t)(unsigned long, unsigned long, void *); diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions +++ a/mm/page_alloc.c @@ -3753,23 +3753,6 @@ unsigned long __init find_min_pfn_with_a return find_min_pfn_for_node(MAX_NUMNODES); } -/** - * find_max_pfn_with_active_regions - Find the maximum PFN registered - * - * It returns the maximum PFN based on information provided via - * add_active_range(). - */ -unsigned long __init find_max_pfn_with_active_regions(void) -{ - int i; - unsigned long max_pfn = 0; - - for (i = 0; i < nr_nodemap_entries; i++) - max_pfn = max(max_pfn, early_node_map[i].end_pfn); - - return max_pfn; -} - /* * early_calculate_totalpages() * Sum pages in active regions for movable zone. _ Which is what it should always have been. Only do one thing per patch, please. The presence of the work "also" in the changelog is usually a big hint that it should be split up. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 20:55 ` Andrew Morton @ 2008-07-28 21:16 ` Mel Gorman 0 siblings, 0 replies; 12+ messages in thread From: Mel Gorman @ 2008-07-28 21:16 UTC (permalink / raw) To: Andrew Morton; +Cc: yhlu.kernel, linux-mm On (28/07/08 13:55), Andrew Morton didst pronounce: > On Mon, 28 Jul 2008 21:40:00 +0100 > Mel Gorman <mel@csn.ul.ie> wrote: > > > > how about KERN_DEBUG? > > > > > > please check > > > > > > > Still NAK due to the noise. > > blah. I changed the patch to this: > Seems reasonable, thanks. I'll keep a closer eye on the next -mm release to make sure the discontig mem boot tests are still ok. Acked-by: Mel Gorman <mel@csn.ul.ie> > --- a/include/linux/mm.h~mm-remove-find_max_pfn_with_active_regions > +++ a/include/linux/mm.h > @@ -1041,7 +1041,6 @@ extern unsigned long absent_pages_in_ran > extern void get_pfn_range_for_nid(unsigned int nid, > unsigned long *start_pfn, unsigned long *end_pfn); > extern unsigned long find_min_pfn_with_active_regions(void); > -extern unsigned long find_max_pfn_with_active_regions(void); > extern void free_bootmem_with_active_regions(int nid, > unsigned long max_low_pfn); > typedef int (*work_fn_t)(unsigned long, unsigned long, void *); > diff -puN mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions mm/page_alloc.c > --- a/mm/page_alloc.c~mm-remove-find_max_pfn_with_active_regions > +++ a/mm/page_alloc.c > @@ -3753,23 +3753,6 @@ unsigned long __init find_min_pfn_with_a > return find_min_pfn_for_node(MAX_NUMNODES); > } > > -/** > - * find_max_pfn_with_active_regions - Find the maximum PFN registered > - * > - * It returns the maximum PFN based on information provided via > - * add_active_range(). > - */ > -unsigned long __init find_max_pfn_with_active_regions(void) > -{ > - int i; > - unsigned long max_pfn = 0; > - > - for (i = 0; i < nr_nodemap_entries; i++) > - max_pfn = max(max_pfn, early_node_map[i].end_pfn); > - > - return max_pfn; > -} > - > /* > * early_calculate_totalpages() > * Sum pages in active regions for movable zone. > _ > > > Which is what it should always have been. Only do one thing per patch, > please. The presence of the work "also" in the changelog is usually a > big hint that it should be split up. > > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree 2008-07-28 20:40 ` Mel Gorman 2008-07-28 20:55 ` Andrew Morton @ 2008-07-28 21:24 ` Yinghai Lu 1 sibling, 0 replies; 12+ messages in thread From: Yinghai Lu @ 2008-07-28 21:24 UTC (permalink / raw) To: Mel Gorman; +Cc: akpm, linux-mm On Mon, Jul 28, 2008 at 1:40 PM, Mel Gorman <mel@csn.ul.ie> wrote: > On (28/07/08 13:14), Yinghai Lu didst pronounce: >> > <SNIP> >> > >> > I'm not seeing what different a rename of the parameter will do. Even if >> > the parameter was renamed, it does not mean current trace information during >> > memory initialisation needs to be outputted as KERN_INFO which is what this >> > patch is doing. I am still failing to understand why you want this information >> > to be generally available. >> >> how about KERN_DEBUG? >> >> please check >> > > Still NAK due to the noise. Admittedly, I introduced the noise > in the first place but it was complained about then as well. See > http://lkml.org/lkml/2006/11/27/124 and later this > http://lkml.org/lkml/2006/11/27/134 . > > At the risk of repeating myself, I am still failing to understand why you want > this information to be generally available at any loglevel. My expectation is > that the information is only of relevance when debugging memory initialisation > problems in which case mminit_loglevel can be used. ok. how do think about using meminit_debug to replace minit_loglevel? YH -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-07-28 21:24 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200807280313.m6S3DHDk017400@imap1.linux-foundation.org>
2008-07-28 9:16 ` + mm-remove-find_max_pfn_with_active_regions.patch added to -mm tree Mel Gorman
2008-07-28 11:15 ` Yinghai Lu
2008-07-28 11:38 ` Mel Gorman
2008-07-28 18:25 ` Yinghai Lu
2008-07-28 19:15 ` Mel Gorman
2008-07-28 19:38 ` Yinghai Lu
2008-07-28 20:00 ` Mel Gorman
2008-07-28 20:14 ` Yinghai Lu
2008-07-28 20:40 ` Mel Gorman
2008-07-28 20:55 ` Andrew Morton
2008-07-28 21:16 ` Mel Gorman
2008-07-28 21:24 ` Yinghai Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox