LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: KyongHo Cho <pullip.cho@samsung.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	KeyYoung Park <keyyoung.park@samsung.com>,
	linux-kernel@vger.kernel.org, Ilho Lee <ilho215.lee@samsung.com>,
	linux-mm@kvack.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: mm: Regarding section when dealing with meminfo
Date: Thu, 20 Jan 2011 10:11:27 -0800	[thread overview]
Message-ID: <1295547087.9039.694.camel@nimitz> (raw)
In-Reply-To: <20110120180146.GH6335@n2100.arm.linux.org.uk>

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


  reply	other threads:[~2011-01-20 18:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-20  9:45 KyongHo Cho
2011-01-20 14:28 ` Minchan Kim
2011-01-20 17:25   ` Dave Hansen
     [not found]   ` <AANLkTinXAiShaf1f69ufVHg7KPaY5j=jmOTtK71GNNp5@mail.gmail.com>
2011-01-20 17:43     ` Minchan Kim
2011-01-20 17:44       ` Minchan Kim
2011-01-20 17:52         ` KyongHo Cho
2011-01-20 17:20 ` Dave Hansen
     [not found]   ` <AANLkTi=nsAOtLPK75Wy5Rm8pfWob8xTP5259DyYuxR9J@mail.gmail.com>
2011-01-20 17:48     ` KyongHo Cho
2011-01-20 18:04     ` Dave Hansen
2011-01-20 18:01   ` Russell King - ARM Linux
2011-01-20 18:11     ` Dave Hansen [this message]
2011-01-23 18:05       ` Russell King - ARM Linux
2011-01-24 16:52         ` Dave Hansen
2011-01-24 17:58           ` Russell King - ARM Linux
2011-01-24 18:47             ` Dave Hansen
2011-01-25  0:33             ` KyongHo Cho
2011-01-21  2:12     ` KyongHo Cho
2011-01-21 10:38       ` Russell King - ARM Linux
2011-01-21 11:15         ` KyongHo Cho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295547087.9039.694.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=ilho215.lee@samsung.com \
    --cc=keyyoung.park@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=pullip.cho@samsung.com \
    --subject='Re: [PATCH] ARM: mm: Regarding section when dealing with meminfo' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).