LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages
Date: Fri, 26 Jan 2007 17:20:07 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701261703200.23091@skynet.skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0701260855560.6966@schroedinger.engr.sgi.com>

On Fri, 26 Jan 2007, Christoph Lameter wrote:

> On Fri, 26 Jan 2007, Mel Gorman wrote:
>
>>> For arches that do not have HIGHMEM other zones would be okay too it
>>> seems.
>> It would, but it'd obscure the code to take advantage of that.
>
> No MOVABLE memory for 64 bit platforms that do not have HIGHMEM right now?
>

err, no, I misinterpreted what you meant by "other zones would be ok..". I 
though you were suggesting the reuse of zone names for some reason.

The zone used to for ZONE_MOVABLE is the highest populated zone on the 
architecture. On some architectures, that will be ZONE_HIGHMEM. On others, 
it will be ZONE_DMA. See the function find_usable_zone_for_movable()

ZONE_MOVABLE never spans zones. For example, it will not use some 
ZONE_HIGHMEM and some ZONE_NORMAL memory.

>> The anti-fragmentation code could potentially be used to have subzone groups
>> that kept movable and unmovable allocations as far apart as possible and at
>> opposite ends of a zone. That approach has been kicked a few times because of
>> complexity.
>
> Hmm... But his patch also introduces additional complexity plus its
> difficult to handle for the end user.
>

It's harder for the user to setup all right. But it works within limits 
that are known well in advance and doesn't add additional code to the main 
allocator path. Once it's setup, it acts like any other zone and zone 
behavior is better understood than anti-fragmentations behavior.

>>> There are some NUMA architectures that are not that
>>> symmetric.
>> I know, it's why find_zone_movable_pfns_for_nodes() is as complex as it is.
>> The mechanism spreads the unmovable memory evenly throughout all nodes. In the
>> event some nodes are too small to hold their share, the remaining unmovable
>> memory is divided between the nodes that are larger.
>
> I would have expected a percentage of a node. If equal amounts of
> unmovable memory are assigned to all nodes at first then there will be
> large disparities in the amount of movable memories f.e. between a node
> with 8G memory compared to a node with 1GB memory.
>

On the other hand, percentages make it harder for the administrator to 
know in advance how much unmovable memory will be available when the 
system starts even if the machine changes configuration. The absolute 
figure is easier to understand. If there was a requirement, an alternative 
configuration option could be made available that takes a fixed percentage 
of each node with memory.

> How do you handle headless nodes? I.e. memory nodes with no processors?

The code only cares about memory, not processors.

> Those may be particularly large compared to the rest but these are mainly
> used for movable pages since unmovable things like device drivers buffers
> have to be kept near the processors that take the interrupt.
>

Then what I'd do is specify kernelcore to be

(number_of_nodes_with_processors * largest_amount_of_memory_on_node_with_processors)

That would have all memory near processors available as unmovable memory 
(that movable allocations will still use so they don't always go remote) 
while keeping a large amount of memory on the headless nodes for movable 
allocations only.

If requirements demanded, a configuration option could be made that allows 
the administrator to specify exactly how much unmovable memory he wants on 
a specific node.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

      reply	other threads:[~2007-01-26 17:20 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 23:44 Mel Gorman
2007-01-25 23:45 ` [PATCH 1/8] Add __GFP_MOVABLE for callers to flag allocations that may be migrated Mel Gorman
2007-01-26 12:27   ` Nick Piggin
2007-01-26 13:25     ` Mel Gorman
2007-01-25 23:45 ` [PATCH 2/8] Create the ZONE_MOVABLE zone Mel Gorman
2007-01-26 16:28   ` Christoph Lameter
2007-01-26 16:49     ` Mel Gorman
2007-01-29 17:28     ` Mel Gorman
2007-01-26 17:16   ` Christoph Lameter
2007-01-26 17:24     ` Mel Gorman
2007-01-26 17:25       ` Christoph Lameter
2007-01-26 17:38         ` Mel Gorman
2007-01-29 17:31     ` Mel Gorman
2007-01-25 23:45 ` [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE Mel Gorman
2007-01-26 16:33   ` Christoph Lameter
2007-01-26 16:58     ` Mel Gorman
2007-01-26 17:04       ` Christoph Lameter
2007-01-26 17:20         ` Mel Gorman
2007-01-26 17:22           ` Christoph Lameter
2007-01-26 17:37             ` Mel Gorman
2007-01-26 17:45               ` Christoph Lameter
2007-01-26 17:53                 ` Mel Gorman
2007-01-26 18:20                   ` Christoph Lameter
2007-01-26 20:37                     ` Mel Gorman
2007-01-26 18:35                   ` Chris Friesen
2007-01-26 20:44                     ` Mel Gorman
2007-01-26 21:37                       ` Chris Friesen
2007-01-25 23:46 ` [PATCH 4/8] x86 - Specify amount of kernel memory at boot time Mel Gorman
2007-01-25 23:46 ` [PATCH 5/8] ppc and powerpc " Mel Gorman
2007-01-25 23:46 ` [PATCH 6/8] x86_64 " Mel Gorman
2007-01-25 23:47 ` [PATCH 7/8] ia64 " Mel Gorman
2007-01-25 23:47 ` [PATCH 8/8] Add documentation for additional boot parameter and sysctl Mel Gorman
2007-01-26 11:07 ` [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages Andrew Morton
2007-01-26 14:29   ` Mel Gorman
2007-01-26 16:01     ` Christoph Lameter
2007-01-26 15:56   ` Christoph Lameter
2007-01-26 19:46     ` Andrew Morton
2007-01-26 19:58       ` Christoph Lameter
2007-01-26 20:27         ` Andrew Morton
2007-01-29 21:54           ` Christoph Lameter
2007-01-29 22:36             ` Andrew Morton
2007-01-29 22:45               ` Christoph Lameter
2007-01-29 22:50                 ` Russell King
2007-01-29 23:37                   ` Christoph Lameter
2007-01-30  0:09                     ` Andrew Morton
2007-01-30  9:53                       ` Peter Zijlstra
2007-02-02  5:27                         ` Christoph Lameter
2007-02-02  5:22                       ` Christoph Lameter
2007-01-26 16:21 ` Christoph Lameter
2007-01-26 16:48   ` Mel Gorman
2007-01-26 17:02     ` Christoph Lameter
2007-01-26 17:20       ` Mel Gorman [this message]

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=Pine.LNX.4.64.0701261703200.23091@skynet.skynet.ie \
    --to=mel@csn.ul.ie \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --subject='Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages' \
    /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

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).