linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	lhms-devel@lists.sourceforge.net
Subject: Re: [PATCH 4/7] ppc64 - Specify amount of kernel memory at boot time
Date: Thu, 23 Feb 2006 09:38:24 -0800	[thread overview]
Message-ID: <1140716304.8697.53.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0602231646530.24093@skynet.skynet.ie>

On Thu, 2006-02-23 at 17:19 +0000, Mel Gorman wrote:
> On Thu, 23 Feb 2006, Dave Hansen wrote:
> >> +/* Initialise the size of each zone in a node */
> >> +void __init zone_sizes_init(unsigned int nid,
> >> +		unsigned long kernelcore_pages,
> >> +		unsigned long *zones_size)
> >
> > Minor nit territory: set_zone_sizes(), maybe?
> >
> 
> In this case, the choice of name is to match an x86 function that does 
> something very similar. If one had read through the x86 code and then saw 
> this function, it would set their expectations of what the code is 
> intended to do.

x86 is bad.  Try to do better. :)

> per-node. A node goes no ZONE_EASYRCLM pages if it is not large enough to 
> contain kernelcore_pages. That means that on a system with 2 nodes, 
> kernelcore=512MB will results in 1024MB of ZONE_DMA in total.
> 
> > Also, how do we want to distribute kernelcore memory over each node?
> > The way it is coded up for now, it will all be sliced out of the first
> > node.  I'm not sure that's a good thing.
> 
> It gets set in every node.

They hypervisor has a memory allocator which it uses to piece out memory
to various LPARs.  When things like partition memory resizing or reboots
occur, that memory gets allocated and freed and so forth.

These machines are _also_ NUMA.  Memory can effectively get lumped so
that you can't always get memory on a single NUMA node.  Because of all
of the other actions of other partitions, these conditions are always
changing.  The end result is that the amount of memory which each NUMA
node has *in* *a* *single* *partition* can theoretically change between
reboots.

OK, back to the hapless system admin using kernelcore.  They have a
4-node system with 2GB of RAM in each node for 8GB total.  They use
kernelcore=1GB.  They end up with 4x1GB ZONE_DMA and 4x1GB
ZONE_EASYRCLM.  Perfect.  You can safely remove 4GB of RAM.

Now, imagine that the machine has been heavily used for a while, there
is only 1 node's memory available, but CPUs are available in the same
places as before.  So, you start up your partition again have 8GB of
memory in one node.  Same kernelcore=1GB option.  You get 1x7GB ZONE_DMA
and 1x1GB ZONE_EASYRCLM.  I'd argue this is going to be a bit of a
surprise to the poor admin.

> zones_size[] is what free_area_init() expects to receive so there is not a 
> lot of room to fiddle with it's meaning without causing more trouble.

It is just passed in there as an argument.  If you can think of a way to
make it more understandable, change it in your architecture, and send
the patch for the main one.

> > One other thing, I want to _know_ that variables being compared are in
> > the same units.  When one is called "pages_" something and the other is
> > something "_size", I don't _know_.
> 
> chunk_num_pages ?

No. :)  The words "chunks" and "clumps" have a bit of a stigma, just
like the number "3".  Ask Matt Dobson.

num_pages_WHAT?  node_num_pages?  silly_num_pages?

Chunk is pretty meaningless.

> yep. get_zholes_size() could be split into two functions 
> find_start_easyrclm_pfn() and get_nid_zholes_size(). Would that be pretty 
> clear-cut?

I think so.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-02-23 17:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17 14:15 [PATCH 0/7] Reducing fragmentation using zones v5 Mel Gorman
2006-02-17 14:16 ` [PATCH 1/7] Add __GFP_EASYRCLM flag and update callers Mel Gorman
2006-02-17 14:16 ` [PATCH 2/7] Create the ZONE_EASYRCLM zone Mel Gorman
2006-02-17 14:16 ` [PATCH 3/7] x86 - Specify amount of kernel memory at boot time Mel Gorman
2006-02-17 14:17 ` [PATCH 4/7] ppc64 " Mel Gorman
2006-02-17 17:16   ` Dave Hansen
2006-02-17 19:03     ` Mel Gorman
2006-02-17 19:17       ` Dave Hansen
2006-02-17 19:36         ` Mel Gorman
2006-02-17 21:31     ` Joel Schopp
2006-02-21 14:51     ` Mel Gorman
2006-02-21 17:35       ` Dave Hansen
2006-02-22 16:43         ` Mel Gorman
2006-02-23 16:42           ` Dave Hansen
2006-02-23 17:19             ` Mel Gorman
2006-02-23 17:38               ` Dave Hansen [this message]
2006-02-23 18:01                 ` Mel Gorman
2006-02-23 18:15                   ` Dave Hansen
2006-02-24  0:15                     ` KAMEZAWA Hiroyuki
2006-02-24  9:04                     ` Mel Gorman
2006-02-23 17:40               ` Mike Kravetz
2006-02-17 14:17 ` [PATCH 5/7] At boot, determine what zone memory will hot-add to Mel Gorman
2006-02-17 14:17 ` [PATCH 6/7] Allow HugeTLB allocations to use ZONE_EASYRCLM Mel Gorman
2006-02-17 14:18 ` [PATCH 7/7] Add documentation for extra boot parameters 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=1140716304.8697.53.camel@localhost.localdomain \
    --to=haveblue@us.ibm.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    /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