From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Re: [Discontig-devel] CLUMPS, CHUNKS and GRANULES
Date: Fri, 16 Aug 2002 22:13:35 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905947@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905942@msgid-missing>
>> > - A contiguous group of memory chunks that reside on the same node
>> > are referred to as a clump. Note that a clump may be partially present.
>> > (Note, on some hardware implementations, a clump is the same as a memory
>> > bank or a DIMM).
>> >
>> > - a node consists of multiple clumps of memory. From a NUMA perspective
>> > accesses to all clumps on the node have the same latency. Except for zone issues,
>> > the clumps are treated as equivalent for allocation/performance purposes.
>> >
>> > - each node has a single contiguous mem_map array. The array contains page struct
>> > entries for every page on the node. There are no "holes" in the mem_map array.
>> > The node data area (see below) has pointers to the start of the mem_map entries
>> > for each clump on the node.
>>
>> The mem_map array is the same on each node, copied from the boot_node
>> to all other nodes. It contains page_struct entries for ALL pages on
>> ALL nodes (if I interpret discontig_paging_init() correctly). The
>> first two sentences need to be reformulated.
Arrrghh! Why on earth would you want to do that? How are you going to
atomically update things? Replicating things that are heavily written to is
a bad idea.
> - each node has a single contiguous page_struct array. This array contains page struct
> entries for every page that is actually present on the node. There are no
> "holes" in the page_struct array for non-existent memory. Note that
> adjacent entries in the array are NOT necessarily for contiguous physical
> pages if there are multiple non-contiguous clumps on the node.
This sounds somewhat saner. I haven't read your code again recently (my head
exploded last time I tried), but most people just use the lmem_map array per node
to just have that node's struct pages.
M.
PS. If you wanted to change all the disgusting defns of PLAT_XXXXX to something
readable, that would make a lot of people happy ;-)
next prev parent reply other threads:[~2002-08-16 22:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-16 11:44 [Linux-ia64] Re: [Discontig-devel] CLUMPS, CHUNKS and GRANULES Erich Focht
2002-08-16 21:53 ` Jack Steiner
2002-08-16 22:05 ` Martin J. Bligh
2002-08-16 22:13 ` Martin J. Bligh [this message]
2002-08-16 22:28 ` Jack Steiner
2002-08-16 23:46 ` Martin J. Bligh
2002-08-17 0:26 ` Jack Steiner
2002-08-19 16:33 ` Erich Focht
2002-08-19 21:34 ` Jack Steiner
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=marc-linux-ia64-105590701905947@msgid-missing \
--to=martin.bligh@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox