[patch] mm: suppress pfn range output for zones without pages

[patch] mm: suppress pfn range output for zones without pages

[David Rientjes]

free_area_init_nodes() emits pfn ranges for all zones on the system.
There may be no pages on a higher zone, however, due to memory
limitations or the use of the mem= kernel parameter.  For example:

Zone PFN ranges:
  DMA      0x00000001 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000

The implementation copies the previous zone's highest pfn, if any, as the
next zone's lowest pfn.  If its highest pfn is then greater than the
amount of addressable memory, the upper memory limit is used instead.
Thus, both the lowest and highest possible pfn for higher zones without
memory may be the same.

The output is now suppressed for zones that do not have a valid pfn
range.

Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/page_alloc.c       |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4377,6 +4377,9 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		if (i == ZONE_MOVABLE)
 			continue;
+		if (arch_zone_lowest_possible_pfn[i] ==
+		    arch_zone_highest_possible_pfn[i])
+			continue;
 		printk("  %-8s %0#10lx -> %0#10lx\n",
 				zone_names[i],
 				arch_zone_lowest_possible_pfn[i],

--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[Mel Gorman]

On Thu, Feb 11, 2010 at 01:29:58AM -0800, David Rientjes wrote:
> free_area_init_nodes() emits pfn ranges for all zones on the system.
> There may be no pages on a higher zone, however, due to memory
> limitations or the use of the mem= kernel parameter.  For example:
> 
> Zone PFN ranges:
>   DMA      0x00000001 -> 0x00001000
>   DMA32    0x00001000 -> 0x00100000
>   Normal   0x00100000 -> 0x00100000
> 
> The implementation copies the previous zone's highest pfn, if any, as the
> next zone's lowest pfn.  If its highest pfn is then greater than the
> amount of addressable memory, the upper memory limit is used instead.
> Thus, both the lowest and highest possible pfn for higher zones without
> memory may be the same.
> 
> The output is now suppressed for zones that do not have a valid pfn
> range.
> 

I see no problem with the patch. Was it a major problem or just
confusing?

> Cc: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: David Rientjes <rientjes@google.com>

Reviewed-by: Mel Gorman <mel@csn.ul.ie>

> ---
>  mm/page_alloc.c       |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4377,6 +4377,9 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
>  	for (i = 0; i < MAX_NR_ZONES; i++) {
>  		if (i == ZONE_MOVABLE)
>  			continue;
> +		if (arch_zone_lowest_possible_pfn[i] ==
> +		    arch_zone_highest_possible_pfn[i])
> +			continue;
>  		printk("  %-8s %0#10lx -> %0#10lx\n",
>  				zone_names[i],
>  				arch_zone_lowest_possible_pfn[i],
> 

-- 
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[David Rientjes]

On Thu, 11 Feb 2010, Mel Gorman wrote:

> > free_area_init_nodes() emits pfn ranges for all zones on the system.
> > There may be no pages on a higher zone, however, due to memory
> > limitations or the use of the mem= kernel parameter.  For example:
> > 
> > Zone PFN ranges:
> >   DMA      0x00000001 -> 0x00001000
> >   DMA32    0x00001000 -> 0x00100000
> >   Normal   0x00100000 -> 0x00100000
> > 
> > The implementation copies the previous zone's highest pfn, if any, as the
> > next zone's lowest pfn.  If its highest pfn is then greater than the
> > amount of addressable memory, the upper memory limit is used instead.
> > Thus, both the lowest and highest possible pfn for higher zones without
> > memory may be the same.
> > 
> > The output is now suppressed for zones that do not have a valid pfn
> > range.
> > 
> 
> I see no problem with the patch. Was it a major problem or just
> confusing?
> 

It was just confusing, I don't think anybody would be parsing the kernel 
log for this specifically to determine whether ZONE_NORMAL exists :)

> > Cc: Mel Gorman <mel@csn.ul.ie>
> > Signed-off-by: David Rientjes <rientjes@google.com>
> 
> Reviewed-by: Mel Gorman <mel@csn.ul.ie>
> 

Thanks!

--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[Andrew Morton]

On Thu, 11 Feb 2010 13:26:37 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:

> On Thu, 11 Feb 2010, Mel Gorman wrote:
> 
> > > free_area_init_nodes() emits pfn ranges for all zones on the system.
> > > There may be no pages on a higher zone, however, due to memory
> > > limitations or the use of the mem= kernel parameter.  For example:
> > > 
> > > Zone PFN ranges:
> > >   DMA      0x00000001 -> 0x00001000
> > >   DMA32    0x00001000 -> 0x00100000
> > >   Normal   0x00100000 -> 0x00100000
> > > 
> > > The implementation copies the previous zone's highest pfn, if any, as the
> > > next zone's lowest pfn.  If its highest pfn is then greater than the
> > > amount of addressable memory, the upper memory limit is used instead.
> > > Thus, both the lowest and highest possible pfn for higher zones without
> > > memory may be the same.
> > > 
> > > The output is now suppressed for zones that do not have a valid pfn
> > > range.
> > > 
> > 
> > I see no problem with the patch. Was it a major problem or just
> > confusing?
> > 
> 
> It was just confusing, I don't think anybody would be parsing the kernel 
> log for this specifically to determine whether ZONE_NORMAL exists :)
> 
> > > Cc: Mel Gorman <mel@csn.ul.ie>
> > > Signed-off-by: David Rientjes <rientjes@google.com>
> > 
> > Reviewed-by: Mel Gorman <mel@csn.ul.ie>
> > 
> 
> Thanks!

I ducked this patch because Christoph's complaint sounded reasonable -
by suppressing this output we're removing information.

--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[Christoph Lameter]

On Thu, 11 Feb 2010, David Rientjes wrote:

> The output is now suppressed for zones that do not have a valid pfn
> range.

There is a difference between zone support not compiled into the kernel
and the zone being empty. The output so far allows me to see that support
for a zone was compiled into the kernel but it is empty.

--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[David Rientjes]

On Thu, 11 Feb 2010, Christoph Lameter wrote:

> > The output is now suppressed for zones that do not have a valid pfn
> > range.
> 
> There is a difference between zone support not compiled into the kernel
> and the zone being empty. The output so far allows me to see that support
> for a zone was compiled into the kernel but it is empty.
> 

So you want to parse this table of zone pfn ranges to determine, for 
example, whether CONFIG_HIGHMEM was enabled for i386 kernels?  That 
doesn't tell you whether its CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G, so 
it's a pretty bad way to interpret the kernel config and decide whether 
the pfn ranges are valid or not.  The only other use case would be to find 
if the values are sane when we don't have CONFIG_ZONE_DMA or 
CONFIG_ZONE_DMA32, but those typically aren't even disabled: I just sent a 
patch to the x86 maintainers to get that configuration to compile on -rc7.  

In other words, I don't think we need to be emitting kernel diagnostic 
messages for zones that are empty and unused just because they are enabled 
in the kernel config; no developer is going to care about parsing the 
usecase I showed in the changelog since ZONE_NORMAL is always defined.

--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[Christoph Lameter]

On Thu, 11 Feb 2010, David Rientjes wrote:

> So you want to parse this table of zone pfn ranges to determine, for
> example, whether CONFIG_HIGHMEM was enabled for i386 kernels?  That
> doesn't tell you whether its CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G, so
> it's a pretty bad way to interpret the kernel config and decide whether

It tells me that there is highmem zone.

> the pfn ranges are valid or not.  The only other use case would be to find
> if the values are sane when we don't have CONFIG_ZONE_DMA or
> CONFIG_ZONE_DMA32, but those typically aren't even disabled: I just sent a
> patch to the x86 maintainers to get that configuration to compile on -rc7.

CONFIG_ZONE_DMA32 is disabled on 32 bit
CONFIG_ZONE_DMA may be disabled on IA64 or other platforms that do have
priviledged areas of memory.

Strange embedded kernel configs may sometimes play tricks with ZONE_DMA.

> In other words, I don't think we need to be emitting kernel diagnostic
> messages for zones that are empty and unused just because they are enabled
> in the kernel config; no developer is going to care about parsing the
> usecase I showed in the changelog since ZONE_NORMAL is always defined.

The kernel zone based arrays will still be dimensioned based on the
configured zones even if you omit those from the display. This influences
memory allocation.

I do not feel strongly about this since I can always look at the .config
files but you are removing information from the kernel log that I have
been using in the past.

--
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>

[patch v2] mm: suppress pfn range output for zones without pages

[David Rientjes]

On Thu, 11 Feb 2010, Christoph Lameter wrote:

> > So you want to parse this table of zone pfn ranges to determine, for
> > example, whether CONFIG_HIGHMEM was enabled for i386 kernels?  That
> > doesn't tell you whether its CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G, so
> > it's a pretty bad way to interpret the kernel config and decide whether
> 
> It tells me that there is highmem zone.
> 

Not as far as the user is concerned, it's empty.  Your point was to 
determine what support was compiled into the kernel and the presence of a 
highmem pfn range does not point to either CONFIG_HIGHMEM4G or 
CONFIG_HIGHMEM64G.

> > the pfn ranges are valid or not.  The only other use case would be to find
> > if the values are sane when we don't have CONFIG_ZONE_DMA or
> > CONFIG_ZONE_DMA32, but those typically aren't even disabled: I just sent a
> > patch to the x86 maintainers to get that configuration to compile on -rc7.
> 
> CONFIG_ZONE_DMA32 is disabled on 32 bit
> CONFIG_ZONE_DMA may be disabled on IA64 or other platforms that do have
> priviledged areas of memory.
> 
> Strange embedded kernel configs may sometimes play tricks with ZONE_DMA.
> 

If it requires spamming the kernel log for an invalid zone pfn range to 
indicate a zone was compiled into the kernel, then fine.



mm: suppress pfn range output for zones without pages

free_area_init_nodes() emits pfn ranges for all zones on the system.
There may be no pages on a higher zone, however, due to memory
limitations or the use of the mem= kernel parameter.  For example:

Zone PFN ranges:
  DMA      0x00000001 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000

The implementation copies the previous zone's highest pfn, if any, as the
next zone's lowest pfn.  If its highest pfn is then greater than the
amount of addressable memory, the upper memory limit is used instead.
Thus, both the lowest and highest possible pfn for higher zones without
memory may be the same.

The pfn range for zones without memory is now shown as "empty" instead.

Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/page_alloc.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4377,8 +4377,12 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		if (i == ZONE_MOVABLE)
 			continue;
-		printk("  %-8s %0#10lx -> %0#10lx\n",
-				zone_names[i],
+		printk("  %-8s ", zone_names[i]);
+		if (arch_zone_lowest_possible_pfn[i] ==
+				arch_zone_highest_possible_pfn[i])
+			printk("empty\n");
+		else
+			printk("%0#10lx -> %0#10lx\n",
 				arch_zone_lowest_possible_pfn[i],
 				arch_zone_highest_possible_pfn[i]);
 	}

--
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>

Re: [patch v2] mm: suppress pfn range output for zones without pages

[Christoph Lameter]

Reviewed-by: Christoph Lameter <cl@linux-foundation.org>


--
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>

Re: [patch] mm: suppress pfn range output for zones without pages

[Andrew Morton]

On Thu, 11 Feb 2010 14:13:19 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:

> On Thu, 11 Feb 2010, Christoph Lameter wrote:
> 
> > > The output is now suppressed for zones that do not have a valid pfn
> > > range.
> > 
> > There is a difference between zone support not compiled into the kernel
> > and the zone being empty. The output so far allows me to see that support
> > for a zone was compiled into the kernel but it is empty.
> > 
> 
> So you want to parse this table of zone pfn ranges to determine, for 
> example, whether CONFIG_HIGHMEM was enabled for i386 kernels?  That 
> doesn't tell you whether its CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G, so 
> it's a pretty bad way to interpret the kernel config and decide whether 
> the pfn ranges are valid or not.  The only other use case would be to find 
> if the values are sane when we don't have CONFIG_ZONE_DMA or 
> CONFIG_ZONE_DMA32, but those typically aren't even disabled: I just sent a 
> patch to the x86 maintainers to get that configuration to compile on -rc7.  
> 
> In other words, I don't think we need to be emitting kernel diagnostic 
> messages for zones that are empty and unused just because they are enabled 
> in the kernel config; no developer is going to care about parsing the 
> usecase I showed in the changelog since ZONE_NORMAL is always defined.

It also tells us that the zone was represented in BIOS tables, but is
empty.  

Perhaps the zone is always represented in BIOS tables (or the equiv for
other architectures), dunno.  If so, that's not information.

--
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>