From: "Keith Mannthey" <kmannth@gmail.com>
To: "Mel Gorman" <mel@csn.ul.ie>
Cc: akpm@osdl.org, tony.luck@intel.com, linuxppc-dev@ozlabs.org,
ak@suse.de, bob.picco@hp.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9
Date: Mon, 21 Aug 2006 11:52:39 -0700 [thread overview]
Message-ID: <a762e240608211152x5d4f11f0wd26f7e3d75d38e0a@mail.gmail.com> (raw)
In-Reply-To: <20060821134518.22179.46355.sendpatchset@skynet.skynet.ie>
On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
> This is V9 of the patchset to size zones and memory holes in an
> architecture-independent manner. It booted successfully on 5 different
> machines (arches were x86, x86_64, ppc64 and ia64) in a number of different
> configurations and successfully built a kernel. If it fails on any machine,
> booting with loglevel=8 and the console log should tell me what went wrong.
>
I am wondering why this new api didn't cleanup the pfn_to_nid code
path as well. Arches are left to still keep another set of
nid-start-end info around. We are sending info like
add_active_range(unsigned int nid, unsigned long start_pfn, unsigned
long end_pfn)
With this info making a common pnf_to_nid seems to be of intrest so we
don't have to keep redundant information in both generic and arch
specific data structures.
Are you intending the hot-add memory code path to call add_active_range or ???
Thanks,
Keith
next prev parent reply other threads:[~2006-08-21 18:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-21 13:45 [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9 Mel Gorman
2006-08-21 13:45 ` [PATCH 1/6] Introduce mechanism for registering active regions of memory Mel Gorman
2006-08-21 13:45 ` [PATCH 2/6] Have Power use add_active_range() and free_area_init_nodes() Mel Gorman
2006-08-21 13:46 ` [PATCH 3/6] Have x86 use add_active_range() and free_area_init_nodes Mel Gorman
2006-08-21 13:46 ` [PATCH 4/6] Have x86_64 " Mel Gorman
2006-08-30 20:57 ` Keith Mannthey
2006-08-31 15:49 ` Mel Gorman
2006-08-31 17:52 ` Keith Mannthey
2006-08-31 18:40 ` Mel Gorman
2006-09-01 3:08 ` Keith Mannthey
2006-09-01 8:33 ` Mel Gorman
2006-09-01 8:46 ` Mika Penttilä
2006-09-04 15:36 ` Mel Gorman
2006-09-04 15:38 ` Account for holes that are outside the range of physical memory Mel Gorman
2006-09-04 15:39 ` Allow an arch to expand node boundaries Mel Gorman
2006-08-21 13:46 ` [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes Mel Gorman
2006-08-21 13:47 ` [PATCH 6/6] Account for memmap and optionally the kernel image as holes Mel Gorman
2006-08-21 18:52 ` Keith Mannthey [this message]
2006-08-22 8:38 ` [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9 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=a762e240608211152x5d4f11f0wd26f7e3d75d38e0a@mail.gmail.com \
--to=kmannth@gmail.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=bob.picco@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mel@csn.ul.ie \
--cc=tony.luck@intel.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).