linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Christoph Lameter <cl@linux-foundation.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Milton Miller <miltonm@bga.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mel@csn.ul.ie>, Johannes Weiner <hannes@cmpxchg.org>,
	Kukjin Kim <kgene.kim@samsung.com>
Subject: Re: [PATCH] Tight check of pfn_valid on sparsemem - v4
Date: Thu, 29 Jul 2010 17:38:58 -0700	[thread overview]
Message-ID: <1280450338.16922.11735.camel@nimitz> (raw)
In-Reply-To: <20100729221426.GA28699@n2100.arm.linux.org.uk>

On Thu, 2010-07-29 at 23:14 +0100, Russell King - ARM Linux wrote:
> What we need is something which allows us to handle memory scattered
> in several regions of the physical memory map, each bank being a
> variable size. 

Russell, it does sound like you have a pretty pathological case here. :)
It's not one that we've really attempted to address on any other
architectures.

Just to spell it out, if you have 4GB of physical address space, with
512k sections, you need 8192 sections, which means 8192*8 bytes, so it'd
eat 64k of memory.  That's the normal SPARSEMEM case.

SPARSEMEM_EXTREME would be a bit different.  It's a 2-level lookup.
You'd have 16 "section roots", each representing 256MB of address space.
Each time we put memory under one of those roots, we'd fill in a
512-section second-level table, which is designed to always fit into one
page.  If you start at 256MB, you won't waste all those entries.

The disadvantage of SPARSEMEM_EXTREME is that it costs you the extra
level in the lookup.  The space loss in arm's case would only be 16
pointers, which would more than be made up for by the other gains.

The other case where it really makes no sense is when you're populating
a single (or small number) of sections, evenly across the address space.
For instance, let's say you have 16 512k banks, evenly spaced at 256MB
intervals:

	512k@0x00000000
	512k@0x10000000
	512k@0x20000000
	...
	512k@0xF0000000

If you use SPARSEMEM_EXTREME on that it will degenerate to having the
same memory consumption as classic SPARSEMEM, along with the extra
lookup of EXTREME.  But, I haven't heard you say that you have this kind
of configuration, yet. :)

SPARSEMEM_EXTREME is really easy to test.  You just have to set it in
your .config.  To get much use out of it, you'd also need to make the
SECTION_SIZE, like the 512k we were talking about.


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

  parent reply	other threads:[~2010-07-30  0:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26 15:46 [PATCH] Tight check of pfn_valid on sparsemem - v4 Minchan Kim
2010-07-26 16:40 ` Christoph Lameter
2010-07-26 22:47   ` Minchan Kim
     [not found]   ` <pfn.valid.v4.reply.1@mdm.bga.com>
     [not found]     ` <AANLkTimtTVvorrR9pDVTyPKj0HbYOYY3aR7B-QWGhTei@mail.gmail.com>
2010-07-27  8:12       ` Milton Miller
2010-07-27  8:13         ` KAMEZAWA Hiroyuki
2010-07-27 10:01           ` Minchan Kim
2010-07-27 14:34             ` Christoph Lameter
2010-07-27 22:33               ` Minchan Kim
2010-07-28 15:14                 ` Christoph Lameter
2010-07-28 15:56                   ` Minchan Kim
2010-07-28 17:02                     ` Christoph Lameter
2010-07-28 22:57                       ` Minchan Kim
2010-07-29 15:46                         ` Christoph Lameter
2010-07-29 16:18                           ` Minchan Kim
2010-07-29 16:47                             ` Christoph Lameter
2010-07-29 17:03                               ` Minchan Kim
2010-07-29 17:30                                 ` Christoph Lameter
2010-07-29 18:33                                   ` Russell King - ARM Linux
2010-07-29 19:55                                     ` Christoph Lameter
2010-07-29 21:13                                       ` Russell King - ARM Linux
2010-07-29 20:55                                     ` Dave Hansen
2010-07-29 22:14                                       ` Russell King - ARM Linux
2010-07-29 22:28                                         ` Christoph Lameter
2010-07-30  0:38                                         ` Dave Hansen [this message]
2010-07-30  9:43                                           ` Minchan Kim
2010-07-30 12:48                                           ` Christoph Lameter
2010-07-30 15:43                                             ` Dave Hansen
2010-07-31 15:30                                             ` Russell King - ARM Linux
2010-08-02 15:48                                               ` Christoph Lameter
2010-07-30  9:32                                       ` Minchan Kim
2010-07-31 10:38                                         ` Russell King - ARM Linux
2010-08-11 15:31                                           ` Dave Hansen
2010-07-27  9:56         ` Minchan Kim

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=1280450338.16922.11735.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --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=miltonm@bga.com \
    --cc=minchan.kim@gmail.com \
    /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 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).