linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: mel@skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@osdl.org>, Andy Whitcroft <apw@shadowen.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
Date: Tue, 5 Dec 2006 17:17:05 +0000	[thread overview]
Message-ID: <20061205171705.GC20614@skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0612050806300.11213@schroedinger.engr.sgi.com>

On (05/12/06 08:14), Christoph Lameter didst pronounce:
> On Mon, 4 Dec 2006, Mel Gorman wrote:
> 
> > 4. Offlining a DIMM
> > 5. Offlining a Node
> > 
> > For Situation 4, a zone may be needed because MAX_ORDER_NR_PAGES would have
> > to be set to too high for anti-frag to be effective. However, zones would
> > have to be tuned at boot-time and that would be an annoying restriction. If
> > DIMMs are being offlined for power reasons, it would be sufficient to be
> > best-effort.
> 
> We are able to depopularize a portion of the pages in a MAX_ORDER chunk if 
> the page structs pages on the borders of that portion are not stored on 
> the DIMM.

Portions of it sure, but to offline the DIMM, all pages must be removed from
it. To guarantee the offlining, that means only __GFP_MOVABLE allocations
are allowed within that area and a zone is the easiest way to do it.

Now, that said, if anti-fragmentation only uses lower PFNs, the number
of active unmovable pages has to be large enough to span all DIMMs
before the offlining would fail. This problem will be hit in some
situations.

> Set a flag in the page struct of those page struct pages 
> straddling the border and free the page struct pages describing only
> memory in the DIMM.
> 

I'm not sure what you mean by this. If I wanted to offline a DIMM and I had
anti-frag (specifically the portion of it that allows a flag that affects a
whole block of pages), I would mark all the MAX_ORDER_NR_PAGES blocks there
as going offline so that the pages will not be reallocated. Some time in
the future, the DIMM will be offlined but it could be an indefinte length
of time. If the DIMM consisted of just ZONE_MOVABLE, it could be offlined
in the length of time it takes to migrate all pages elsewhere or page them out.

> > Situation 5 requires that a hotpluggable node only allows __GFP_MOVABLE
> > allocations in the zonelists. This would probably involving having one
> > zone that only allowed __GFP_MOVABLE.
> 
> This is *node* hotplug and we already have a node/zone structure etc where 
> we could set some option to require only movable allocations.

True. It would be a bit of a hack, but it's work without needing zones.

> Note that 
> NUMA nodes have always had only a single effective zone. There are some 
> exceptions on some architectures where we have additional DMA zones on the 
> first or first two nodes but NUMA memory policies will *not* allow to 
> exercise control over allocations from those zones.
> 
> > In other words, to properly address all situations, we may need anti-frag
> > and zones, not one or the other.
> 
> I still do not see a need for additional zones.

It's needed if you want to 100% guarantee the ability to offline a DIMM under
all circumstances. However, ZONE_MOVABLE comes with it's own problems such
as not allowing kernel allocations like network buffers.

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

--
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-12-05 17:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30 17:07 Mel Gorman
2006-12-01  1:31 ` Andrew Morton
2006-12-01  9:54   ` Mel Gorman
2006-12-01 19:01     ` Andrew Morton
2006-12-04 14:07       ` Mel Gorman
2006-12-04 19:30         ` Andrew Morton
2006-12-04 19:41           ` Christoph Lameter
2006-12-04 20:06             ` Andrew Morton
2006-12-04 20:17               ` Christoph Lameter
2006-12-04 21:19                 ` Andrew Morton
2006-12-04 21:43                   ` Christoph Lameter
2006-12-04 22:22                     ` Andrew Morton
2006-12-05 16:00                       ` Christoph Lameter
2006-12-05 19:25                         ` Andrew Morton
2006-12-05 20:01                           ` Christoph Lameter
2006-12-05 21:47                             ` Mel Gorman
2006-12-05 23:33                               ` Christoph Lameter
2006-12-06  9:31                                 ` Mel Gorman
2006-12-06 17:31                                   ` Christoph Lameter
2006-12-08  1:21                                     ` Jeremy Fitzhardinge
2006-12-08  2:20                                       ` Christoph Lameter
2006-12-08  6:11                                         ` Jeremy Fitzhardinge
2006-12-05 18:10                       ` Mel Gorman
2006-12-04 20:34           ` Mel Gorman
2006-12-04 22:34             ` Andrew Morton
2006-12-04 23:45               ` Mel Gorman
2006-12-05  1:16                 ` KAMEZAWA Hiroyuki
2006-12-05 10:03                   ` Mel Gorman
2006-12-05 16:05                     ` Christoph Lameter
2006-12-05 18:26                       ` Andrew Morton
2006-12-05 19:59                         ` Christoph Lameter
2006-12-05 16:14                 ` Christoph Lameter
2006-12-05 17:17                   ` Mel Gorman [this message]
2006-12-05 19:54                     ` Christoph Lameter
2006-12-05 15:52               ` Andy Whitcroft
2006-12-05 15:48             ` Andy Whitcroft
2006-12-04 20:37           ` Peter Zijlstra
2006-12-06 14:18             ` Andy Whitcroft

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=20061205171705.GC20614@skynet.ie \
    --to=mel@skynet.ie \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox