lkml.org 
[lkml]   [2011]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ARM: mm: Regarding section when dealing with meminfo
From
Date
On Thu, 2011-01-20 at 18:01 +0000, Russell King - ARM Linux wrote:
> > The x86 version of show_mem() actually manages to do this without any
> > #ifdefs, and works for a ton of configuration options. It uses
> > pfn_valid() to tell whether it can touch a given pfn.
>
> x86 memory layout tends to be very simple as it expects memory to
> start at the beginning of every region described by a pgdat and extend
> in one contiguous block. I wish ARM was that simple.

x86 memory layouts can be pretty funky and have been that way for a long
time. That's why we *have* to handle holes in x86's show_mem(). My
laptop even has a ~1GB hole in its ZONE_DMA32:

[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x0013c000

But:

Node 0, zone DMA32
pages free 82877
min 12783
low 15978
high 19174
scanned 0
spanned 1044480
present 765672

See how the present is ~1GB less than spanned? That's because of an I/O
hole from ~3-4GB:

# cat /proc/iomem | grep RAM
00010000-0009d7ff : System RAM
00100000-bf6affff : System RAM
100000000-13bffffff : System RAM

I guess if we were being really smart we'd just shrink the DMA32 zone
down and not even cover that area. But, we don't.

Memory hotplug was the original reason that we put sparsemem in place,
but we also have plenty of configurations where there are holes in the
middle of zones and pgdats.

-- Dave



\
 
 \ /
  Last update: 2011-01-20 19:13    [W:0.097 / U:10.288 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site