From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch 0/4] V2 ia64 SPARSEMEM
Date: Wed, 25 May 2005 22:44:06 +0000 [thread overview]
Message-ID: <20050525224406.GA22989@sgi.com> (raw)
In-Reply-To: <20050525151347.GB23448@localhost.localdomain>
On Wed, May 25, 2005 at 11:13:47AM -0400, Bob Picco wrote:
...
> and HPSIM. An early version of ia64 with SPARSEMEM was tested by Jesse. It
> would be optimal to have another test pass on SGI NUMA hardware.
I'm away from the office this week, but next week, I'll give the patch
another spin on a big SGI system.
>
>
> VIRTUAL_MEM_MAP was introduced on ia64 because of memory holes on ia64
> platforms. The mem_map of the pglist_data is a pointer to a virtual
> contiguous array of page structures in memory for a node. To
> eliminate memory waste contiguous memory holes don't have page structures.
> The alternative would be for holes in memory to be represented by reserve
> page structures. The VIRTUAL_MEM_MAP solutions requires ia64_pfn_valid
> and a hook in the buddy allocator to check for holes in memory.
>
> SPARSEMEM has eliminated mem_map, ia64_pfn_valid and the buddy allocator
> hook. There is a small cost for SPARSEMEM. Any section which has both
> memory and holes requires reserved pages for the holes. I can see
Our systems are notorious for having large holes in memory on nodes. For example,
a node may have memory at node offsets 0, 16GB, 32GB & 48GB. At each offset, you
can have a chunk of 1 to 16GB. For example, a typical system might have memory
at the following node offsets:
Memory at
0 - 4GB
16 - 20GB
32 - 36GB
48 - 52GB
You are guaranteed to have memory at node offset 0. Memory may or
may not exist at the other offsets.
I haven't had a chance to look at the patch, but will page struct entries
will be allocated for the pages in the holes (4GB-16GB, etc).
--
Thanks
Jack Steiner (steiner@sgi.com) 651-683-5302
Principal Engineer SGI - Silicon Graphics, Inc.
next prev parent reply other threads:[~2005-05-25 22:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-25 15:13 [patch 0/4] V2 ia64 SPARSEMEM Bob Picco
2005-05-25 22:44 ` Jack Steiner [this message]
2005-05-25 23:20 ` Bob Picco
2005-06-09 19:47 ` Jack Steiner
2005-06-09 19:59 ` Bob Picco
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=20050525224406.GA22989@sgi.com \
--to=steiner@sgi.com \
--cc=linux-ia64@vger.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.