mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rohit Seth <rohitseth@google.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andi Kleen <ak@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	David Rientjes <rientjes@cs.washington.edu>,
	Paul Menage <menage@google.com>, Andrew Morton <akpm@osdl.org>
Subject: Re: [Patch1/4]: fake numa for x86_64 patch
Date: Mon, 27 Nov 2006 10:22:41 -0800	[thread overview]
Message-ID: <1164651761.6619.33.camel@galaxy.corp.google.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0611271310200.11949@skynet.skynet.ie>

Hi Mel, 

On Mon, 2006-11-27 at 13:18 +0000, Mel Gorman wrote:
> On Wed, 22 Nov 2006, Rohit Seth wrote:
> 
> > This patch provides a IO hole size in a given address range.
> >
> 
> Hi,
> 
> This patch reintroduces a function that doubles up what 
> absent_pages_in_range(start_pfn, end_pfn). I recognise you do this because 
> you are interested in hole sizes before add_active_range() is called.

Right.

>  
> However, what is not clear is why these patches are so specific to x86_64.
> 

Specifically in the fake numa case, we want to make sure that we don't
carve fake nodes that only have IO holes in it.  Unlike the real NUMA
case, here we don't have SRAT etc. to know the memory layout beforehand.

 
> It looks possible to do the work of functions like split_nodes_equal() in 
> an architecture-independent manner using early_node_map rather than 
> dealing with the arch-specific nodes array. That would open the 
> possibility of providing fake nodes on more than one architecture in the 
> future.

The functions like splti_nodes_equal etc. can be abstracted out to arch
independent part.  I think the only API it needs from arch dependent
part is to find out how much real RAM is present in range without have
to first do add_active_range.

Though as a first step, let us fix the x86_64 (as it doesn't boot when
you have sizeable chunk of IO hole and nodes > 4).

I'm also not sure if other archs actually want to have this
functionality.

> What I think can be done is that you register memory as normal and then 
> split up the nodes into fake nodes. This would remove the need for having 
> e820_hole_size() reintroduced.

Are you saying first let the system find out real numa topology and then
build fake numa on top of it?

-rohit


  reply	other threads:[~2006-11-27 18:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-23  1:34 Rohit Seth
2006-11-27 13:18 ` Mel Gorman
2006-11-27 18:22   ` Rohit Seth [this message]
2006-11-28 13:24     ` Mel Gorman
2006-11-28 18:06       ` Rohit Seth
2006-11-28 21:34         ` Mel Gorman
2006-11-28 22:20           ` Rohit Seth

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=1164651761.6619.33.camel@galaxy.corp.google.com \
    --to=rohitseth@google.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=menage@google.com \
    --cc=rientjes@cs.washington.edu \
    /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

all inboxes | Powered by JetHome®