From: mel@skynet.ie (Mel Gorman)
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-mm@kvack.org, Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
ak@suse.de, akpm@linux-foundation.org, pj@sgi.com
Subject: Re: NUMA policy issues with ZONE_MOVABLE
Date: Thu, 26 Jul 2007 17:16:52 +0100 [thread overview]
Message-ID: <20070726161652.GA16556@skynet.ie> (raw)
In-Reply-To: <20070726131539.8a05760f.kamezawa.hiroyu@jp.fujitsu.com>
On (26/07/07 13:15), KAMEZAWA Hiroyuki didst pronounce:
> On Wed, 25 Jul 2007 12:31:21 -0700 (PDT)
> Christoph Lameter <clameter@sgi.com> wrote:
> > So for a __GFP_MOVABLE alloc we would scan all zones and for
> > policy_zone just the policy zone.
> >
> > Lee should probably also review this in detail since he has recent
> > experience fiddling around with memory policies. Paul has also
> > experience in this area.
> >
> > Maybe this can actually help to deal with some of the corner cases of
> > memory policies (just hope the performance impact is not significant).
> >
> >
>
> Hmm, How about following patch ? (not tested, just an idea).
> I'm sorry if I misunderstand concept ot policy_zone.
>
The following seems like a good idea to do anyway.
> ==
> Index: linux-2.6.23-rc1/include/linux/mempolicy.h
> ===================================================================
> --- linux-2.6.23-rc1.orig/include/linux/mempolicy.h
> +++ linux-2.6.23-rc1/include/linux/mempolicy.h
> @@ -162,14 +162,11 @@ extern struct zonelist *huge_zonelist(st
> unsigned long addr, gfp_t gfp_flags);
> extern unsigned slab_node(struct mempolicy *policy);
>
> +/*
> + * The smalles zone_idx which all nodes can offer against GFP_xxx
> + */
> extern enum zone_type policy_zone;
>
The comment is a little misleading
/* policy_zone is the lowest zone index that is present on all nodes */
Right?
> -static inline void check_highest_zone(enum zone_type k)
> -{
> - if (k > policy_zone)
> - policy_zone = k;
> -}
> -
> int do_migrate_pages(struct mm_struct *mm,
> const nodemask_t *from_nodes, const nodemask_t *to_nodes, int flags);
>
> Index: linux-2.6.23-rc1/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.23-rc1.orig/mm/page_alloc.c
> +++ linux-2.6.23-rc1/mm/page_alloc.c
> @@ -1648,7 +1648,6 @@ static int build_zonelists_node(pg_data_
> zone = pgdat->node_zones + zone_type;
> if (populated_zone(zone)) {
> zonelist->zones[nr_zones++] = zone;
> - check_highest_zone(zone_type);
> }
>
> } while (zone_type);
> @@ -1857,7 +1856,6 @@ static void build_zonelists_in_zone_orde
> z = &NODE_DATA(node)->node_zones[zone_type];
> if (populated_zone(z)) {
> zonelist->zones[pos++] = z;
> - check_highest_zone(zone_type);
> }
> }
> }
> @@ -1934,6 +1932,7 @@ static void build_zonelists(pg_data_t *p
> int local_node, prev_node;
> struct zonelist *zonelist;
> int order = current_zonelist_order;
> + int highest_zone;
>
> /* initialize zonelists */
> for (i = 0; i < MAX_NR_ZONES; i++) {
> @@ -1981,6 +1980,32 @@ static void build_zonelists(pg_data_t *p
> /* calculate node order -- i.e., DMA last! */
> build_zonelists_in_zone_order(pgdat, j);
> }
> + /*
> + * Find the lowest zone where mempolicy (MBID) can work well.
> + */
/*
* Find the lowest zone such that using the MPOL_BIND policy with
* an arbitrary set of nodes will not go OOM because a suitable
* zone was unavailable
*/
> + highest_zone = 0;
> + policy_zone = -1;
> + for (i = 0; i < MAX_NR_ZONES; i++) {
> + struct zone *first_zone;
> + int success = 1;
> + for_each_node_state(node, N_MEMORY) {
> + first_zone = NODE_DATA(node)->node_zonelists[i][0];
> + if (zone_idx(first_zone) > highest_zone)
> + highest_zone = zone_idx(first_zone);
> + if (first_zone->zone_pgdat != NODE_DATA(node)) {
> + /* This node cannot offer right pages for this
> + GFP */
> + success = 0;
> + break;
> + }
The second "if" needs to go first I believe.
> + }
> + if (success) {
> + policy_zone = i;
> + break;
> + }
> + }
> + if (policy_zone == -1)
> + policy_zone = highest_zone;
> }
>
> /* Construct the zonelist performance cache - see further mmzone.h */
--
--
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>
next prev parent reply other threads:[~2007-07-26 16:16 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-25 4:20 Christoph Lameter
2007-07-25 4:47 ` Nick Piggin
2007-07-25 5:05 ` Christoph Lameter
2007-07-25 5:24 ` Nick Piggin
2007-07-25 6:00 ` Christoph Lameter
2007-07-25 6:09 ` Nick Piggin
2007-07-25 9:32 ` Andi Kleen
2007-07-25 6:36 ` KAMEZAWA Hiroyuki
2007-07-25 11:16 ` Mel Gorman
2007-07-25 14:30 ` Lee Schermerhorn
2007-07-25 19:31 ` Christoph Lameter
2007-07-26 4:15 ` KAMEZAWA Hiroyuki
2007-07-26 4:53 ` Christoph Lameter
2007-07-26 7:41 ` KAMEZAWA Hiroyuki
2007-07-26 16:16 ` Mel Gorman [this message]
2007-07-26 18:03 ` Christoph Lameter
2007-07-26 18:26 ` Mel Gorman
2007-07-26 13:23 ` Mel Gorman
2007-07-26 18:07 ` Christoph Lameter
2007-07-26 22:59 ` Mel Gorman
2007-07-27 1:22 ` Christoph Lameter
2007-07-27 8:20 ` Mel Gorman
2007-07-27 15:45 ` Mel Gorman
2007-07-27 17:35 ` Christoph Lameter
2007-07-27 17:46 ` Mel Gorman
2007-07-27 18:38 ` Christoph Lameter
2007-07-27 18:00 ` [PATCH] Document Linux Memory Policy - V2 Lee Schermerhorn
2007-07-27 18:38 ` Randy Dunlap
2007-07-27 19:01 ` Lee Schermerhorn
2007-07-27 19:21 ` Randy Dunlap
2007-07-27 18:55 ` Christoph Lameter
2007-07-27 19:24 ` Lee Schermerhorn
2007-07-31 15:14 ` Mel Gorman
2007-07-31 16:34 ` Lee Schermerhorn
2007-07-31 19:10 ` Christoph Lameter
2007-07-31 19:46 ` Lee Schermerhorn
2007-07-31 19:58 ` Christoph Lameter
2007-07-31 20:23 ` Lee Schermerhorn
2007-07-31 20:48 ` [PATCH] Document Linux Memory Policy - V3 Lee Schermerhorn
2007-08-03 13:52 ` Mel Gorman
2007-07-28 7:28 ` NUMA policy issues with ZONE_MOVABLE KAMEZAWA Hiroyuki
2007-07-28 11:57 ` Mel Gorman
2007-07-28 14:10 ` KAMEZAWA Hiroyuki
2007-07-28 14:21 ` KAMEZAWA Hiroyuki
2007-07-30 12:41 ` Mel Gorman
2007-07-30 18:06 ` Christoph Lameter
2007-07-27 14:24 ` Lee Schermerhorn
2007-08-01 18:59 ` Lee Schermerhorn
2007-08-02 0:36 ` KAMEZAWA Hiroyuki
2007-08-02 17:10 ` Mel Gorman
2007-08-02 17:51 ` Lee Schermerhorn
2007-07-26 18:09 ` Lee Schermerhorn
2007-08-02 14:09 ` Mel Gorman
2007-08-02 18:56 ` Christoph Lameter
2007-08-02 19:42 ` Mel Gorman
2007-08-02 19:52 ` Christoph Lameter
2007-08-03 9:32 ` Mel Gorman
2007-08-03 16:36 ` Christoph Lameter
2007-07-25 14:27 ` Lee Schermerhorn
2007-07-25 17:39 ` Mel Gorman
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=20070726161652.GA16556@skynet.ie \
--to=mel@skynet.ie \
--cc=Lee.Schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=pj@sgi.com \
/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