linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: akpm@osdl.org, clameter@sgi.com, apw@shadowen.org,
	linux-mm@kvack.org, 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 10:16:29 +0900	[thread overview]
Message-ID: <20061205101629.5cb78828.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0612042338390.2108@skynet.skynet.ie>

Hi, your plan looks good to me.
some comments.

On Mon, 4 Dec 2006 23:45:32 +0000 (GMT)
Mel Gorman <mel@csn.ul.ie> wrote:
> 1. Use lumpy-reclaim to intelligently reclaim contigous pages. The same
>     logic can be used to reclaim within a PFN range
> 2. Merge anti-frag to help high-order allocations, hugetlbpage
>     allocations and freeing up SPARSEMEM sections of memory
For freeing up SPARSEMEM sections of memory ? 
It looks that you assumes MAX_ORDER_NR_PAGES equals to PAGES_PER_SECTION.
plz don't assume that when you talk about generic arch code.

> 3. Anti-frag includes support for page flags that affected a MAX_ORDER block
>     of pages. These flags can be used to mark a section of memory that should
>     not be allocated from. This is of interest to both hugetlb page allocatoin
>     and memory hot-remove. Use the flags to mark a MAX_ORDER_NR_PAGES that
>     is currently being freed up and shouldn't be allocated. 

> 4. Use anti-frag fallback logic to bias unmovable allocations to the lower
>     PFNs.
I think this can be one of the most diffcult things ;)

> 5. Add arch support where possible for offlining sections of memory that
>     can be powered down.
I had a patch for ACPI-memory-hot-unplug, which ties memory sections to memory
chunk on ACPI.

> 6. Add arch support where possible to power down a DIMM when the memory
>     sections that make it up have been offlined. This is an extenstion of
>     step 5 only.
> 7. Add a zone that only allows __GFP_MOVABLE allocations so that
>     sections can 100% be reclaimed and powered-down
> 8. Allow nodes to only have a zone for __GFP_MOVABLE allocations so that
>     whole nodes can be offlined.
> 
I (numa-node-hotplug) needs 7 and 8 basically. And Other people may not.
IMHO:
For DIMM unplug, I suspect that we'll finally divide memory to core-memory and
hot-pluggable by pgdat even on SMP. If we use pgdat for that purpose, almost all
necessary infrastructure(statistics ,etc..) is ready. 
But if we find better way, it's good.

-Kame

--
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  1:16 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 [this message]
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=20061205101629.5cb78828.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=clameter@sgi.com \
    --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