All of 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: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 13:46:59 -0700	[thread overview]
Message-ID: <1279054019.10995.18.camel@nimitz> (raw)
In-Reply-To: <20100713183932.GB31162@n2100.arm.linux.org.uk>

On Tue, 2010-07-13 at 19:39 +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 13, 2010 at 05:02:22PM +0900, KAMEZAWA Hiroyuki wrote:
> > How about stop using SPARSEMEM ? What's the benefit ? It just eats up
> > memory for mem_section[].
> 
> The problem with that approach is that sometimes the mem_map array
> doesn't fit into any memory banks.
> 
> We've gone around the loop of using flatmem with holes punched in it,
> to using discontigmem, and now to using sparsemem.  It seems none of
> these solutions does what we need for ARM.  I guess that's the price
> we pay for not having memory architected to be at any particular place
> in the physical memory map.

What's the ARM hardware's maximum addressable memory these days? 4GB?

A 4GB system would have 256 sections, which means 256*2*sizeof(unsigned
long) for the mem_section[].  That's a pretty small amount of RAM.

What sizes are the holes that are being punched these days?  Smaller
than 16MB?

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 13:46:59 -0700	[thread overview]
Message-ID: <1279054019.10995.18.camel@nimitz> (raw)
In-Reply-To: <20100713183932.GB31162@n2100.arm.linux.org.uk>

On Tue, 2010-07-13 at 19:39 +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 13, 2010 at 05:02:22PM +0900, KAMEZAWA Hiroyuki wrote:
> > How about stop using SPARSEMEM ? What's the benefit ? It just eats up
> > memory for mem_section[].
> 
> The problem with that approach is that sometimes the mem_map array
> doesn't fit into any memory banks.
> 
> We've gone around the loop of using flatmem with holes punched in it,
> to using discontigmem, and now to using sparsemem.  It seems none of
> these solutions does what we need for ARM.  I guess that's the price
> we pay for not having memory architected to be at any particular place
> in the physical memory map.

What's the ARM hardware's maximum addressable memory these days? 4GB?

A 4GB system would have 256 sections, which means 256*2*sizeof(unsigned
long) for the mem_section[].  That's a pretty small amount of RAM.

What sizes are the holes that are being punched these days?  Smaller
than 16MB?

-- Dave

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

  reply	other threads:[~2010-07-13 20:47 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 15:53 [RFC] Tight check of pfn_valid on sparsemem Minchan Kim
2010-07-12 15:53 ` Minchan Kim
2010-07-12 23:59 ` Kukjin Kim
2010-07-12 23:59   ` Kukjin Kim
2010-07-13  3:19 ` KAMEZAWA Hiroyuki
2010-07-13  3:19   ` KAMEZAWA Hiroyuki
2010-07-13  4:11   ` Minchan Kim
2010-07-13  4:11     ` Minchan Kim
2010-07-13  4:23     ` KAMEZAWA Hiroyuki
2010-07-13  4:23       ` KAMEZAWA Hiroyuki
2010-07-13  6:04       ` Minchan Kim
2010-07-13  6:04         ` Minchan Kim
2010-07-13  6:40         ` KAMEZAWA Hiroyuki
2010-07-13  6:40           ` KAMEZAWA Hiroyuki
2010-07-13  8:06           ` Minchan Kim
2010-07-13  8:06             ` Minchan Kim
2010-07-13  8:03             ` KAMEZAWA Hiroyuki
2010-07-13  8:03               ` KAMEZAWA Hiroyuki
2010-07-13  7:20         ` Russell King - ARM Linux
2010-07-13  7:20           ` Russell King - ARM Linux
2010-07-13  7:34           ` KAMEZAWA Hiroyuki
2010-07-13  7:34             ` KAMEZAWA Hiroyuki
2010-07-13  7:58             ` KAMEZAWA Hiroyuki
2010-07-13  7:58               ` KAMEZAWA Hiroyuki
2010-07-13  8:02               ` KAMEZAWA Hiroyuki
2010-07-13  8:02                 ` KAMEZAWA Hiroyuki
2010-07-13 18:39                 ` Russell King - ARM Linux
2010-07-13 18:39                   ` Russell King - ARM Linux
2010-07-13 20:46                   ` Dave Hansen [this message]
2010-07-13 20:46                     ` Dave Hansen
2010-07-13  9:30 ` Johannes Weiner
2010-07-13  9:30   ` Johannes Weiner
2010-07-13 15:43   ` Minchan Kim
2010-07-13 15:43     ` Minchan Kim
2010-07-13 16:35     ` Dave Hansen
2010-07-13 16:35       ` Dave Hansen
2010-07-13 16:44       ` Minchan Kim
2010-07-13 16:44         ` Minchan Kim
2010-07-14  0:23         ` KAMEZAWA Hiroyuki
2010-07-14  0:23           ` KAMEZAWA Hiroyuki
2010-07-14  6:44           ` Minchan Kim
2010-07-14  6:44             ` Minchan Kim
2010-07-14  7:10             ` KAMEZAWA Hiroyuki
2010-07-14  7:10               ` KAMEZAWA Hiroyuki
2010-07-14  7:35               ` Minchan Kim
2010-07-14  7:35                 ` Minchan Kim
2010-07-14  7:39                 ` KAMEZAWA Hiroyuki
2010-07-14  7:39                   ` KAMEZAWA Hiroyuki
2010-07-14  7:50           ` Kukjin Kim
2010-07-14  7:50             ` Kukjin Kim
2010-07-14  8:09             ` KAMEZAWA Hiroyuki
2010-07-14  8:09               ` KAMEZAWA Hiroyuki
2010-07-13  9:37 ` Mel Gorman
2010-07-13  9:37   ` Mel Gorman
2010-07-13  9:46   ` Russell King - ARM Linux
2010-07-13  9:46     ` Russell King - ARM Linux
2010-07-13 10:00     ` Mel Gorman
2010-07-13 10:00       ` Mel Gorman

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=1279054019.10995.18.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arm-kernel@lists.infradead.org \
    --cc=hpa@zytor.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=shaohua.li@intel.com \
    --cc=yakui.zhao@intel.com \
    --cc=yinghai@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.