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>,
	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 15:33:50 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0612051521060.20570@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20061205214721.GE20614@skynet.ie>

On Tue, 5 Dec 2006, Mel Gorman wrote:

> There are times you want to reclaim just part of a zone - specifically
> satisfying a high-order allocations. See sitations 1 and 2 from elsewhere
> in this thread. On a similar vein, there will be times when you want to
> migrate a PFN range for similar reasons.

This is confusing reclaim with defragmentation. I think we are in 
conceptually unclean territory because we mix the two. If you must use 
reclaim to get a portion of contiguous memory free then yes we have this 
problem. If you can migrate pages then no there is no need for reclaiming 
a part of a zone. You can occasionally shuffle pages around to 
get a large continous chunk. If there is not enough memory then an 
independent reclaim subsystem can take care of freeing a sufficient amount 
of memory. Marrying the two seems to be getting a bit complex and maybe 
very difficult to get right.

The classification of the memory allocations is useful
to find a potential starting point to reduce the minimum number of pages 
to move to open up that hole.

> > Why would one want to allocate from the 1/4th of a zone? (Are we still 
> > discussing Mel's antifrag scheme or what is this about?)
> Because you wanted contiguous blocks of pages.  This is related to anti-frag
> because with anti-frag, reclaiming memory or migration memory will free up
> contiguous blocks. Without it, you're probably wasting your time.

I am still not sure how this should work. Reclaim in a portion of the 
reclaimable/movable portion of the zone? Or pick a huge page and simply 
reclaim all the pages in that range? 

This is required for anti-frag regardless of additonal zones right?

BTW If one would successfully do this partial reclaim thing then we also 
have no need anymore DMA zones because we can free up memory in the DMA 
area of a zone at will if we run short on memory there.


--
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 23:33 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 [this message]
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
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.0612051521060.20570@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@osdl.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