linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Mel Gorman <mel@skynet.ie>
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 11:54:19 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0612051145510.18687@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20061205171705.GC20614@skynet.ie>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3029 bytes --]

On Tue, 5 Dec 2006, Mel Gorman wrote:

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

We were talking about the memory map (page struct array) not the page in 
the DIMM per se. The memory map could also be made movable to deal with 
pages overlapping boundaries (I am not sure that there is really a problem 
at this time, we can probably afford to require the complete removal of a 
page full of page structs. This is true in the the vmemmap case. 
Sparsemem has large memmap chunks that may span multiple pages but 
that could be fixed by changing the chunk size.

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

You have a block full of page structs (that is placed on other memory than 
the DIMM). Some of the pages belonging to the page structs are in the area 
to be offlined and other are not. Then you can remove the pages to be 
offlined from the freelist (if they are on it) and from usage (by 
migration or recleaim) and then mark them as unused. Marking them as 
unused could then be as simple as setting PG_reserved.
> 
> > 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.

We must have some means of marking a node as removalbe anyways in order 
to support node hotplug® What is so hackish about it?

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

You cannot offline all DIMMS since (at least at this point in time) we 
need memory that is not movable. If you have multiple DIMMS then the 
additional DIMMS may be placed in areas of a zone that cannot take 
unmovable MAX_ORDER_NR_PAGES blocks.

  reply	other threads:[~2006-12-05 19:54 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
2006-12-05 19:54                     ` Christoph Lameter [this message]
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=Pine.LNX.4.64.0612051145510.18687@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@skynet.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