All of lore.kernel.org
 help / color / mirror / Atom feed
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:05:01 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905946@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905942@msgid-missing>

> Discontig is certainly difficult to understand but it is trying
> to provide an abstract framework for describing a very diverse of 
> hardware. The SGI hardware, unfortunately, is likely to be 
> the "worst case" example. :-(

It might help if you didn't try to do everything all at once. If you could
get a subset of the code in and make your patches smaller for you
to maintain ....

>> Therefore a node would have several memory banks which are not
>> necessarily adjacent in the physical memory space. There can be gaps
>> or banks from other nodes interleaved. In the mem_map array there is
>> space reserved for page struct entries of ALL pages of one bank,
>> existent or not. Memory holes between banks don't build holes in the
>> mem_map array.
> 
> If the mem_map has entries for pages that dont exist, how do you handle
> code that scans the mem_map array. How does code recognize  & skip pages
> associated with missing memory?? For examples, see show_mem()
> & get_discontig_info(). (Maybe I misunderstood your proposal here).

show_mem in most architectures is designed for contig mem only.
Pretty much anything that touches mem_map directly is for contig mem
only ... I'm just about done with a patch that wraps the defn of it in
#ifndef CONFIG_DISCONTIGMEM. Will send it out again shortly.

OTOH, I don't think that mem_map having pages for entries that don't exist 
is quite the problem that you think it is - we're only scanning the struct pages,
not the pages themselves.

M.



  parent reply	other threads:[~2002-08-16 22:05 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 [this message]
2002-08-16 22:13 ` Martin J. Bligh
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-105590701905946@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 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.