All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nick Piggin <npiggin@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lin Ming <ming.m.lin@intel.com>,
	Zhang Yanmin <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 24/27] Convert gfp_zone() to use a table of precalculated values
Date: Wed, 18 Mar 2009 18:17:17 +0000	[thread overview]
Message-ID: <20090318181717.GC24462@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.1.10.0903181300540.15570@qirst.com>

On Wed, Mar 18, 2009 at 01:21:30PM -0400, Christoph Lameter wrote:
> 
> 
> > time.
> >
> > > > > const int gfp_zone_table[GFP_ZONEMASK] = {
> > > > > 	ZONE_NORMAL,		/* 00 No flags set */
> > > > > 	ZONE_DMA,		/* 01 Only GFP_DMA set */
> > > > > 	ZONE_HIGHMEM,		/* 02 Only GFP_HIGHMEM set */
> > > > > 	ZONE_DMA,		/* 03 GFP_HIGHMEM and GFP_DMA set */
> > > > > 	ZONE_DMA32,		/* 04 Only GFP_DMA32 set */
> > > > > 	ZONE_DMA,		/* 05 GFP_DMA and GFP_DMA32 set */
> > > > > 	ZONE_DMA32,		/* 06 GFP_DMA32 and GFP_HIGHMEM set */
> > > > > 	ZONE_DMA,		/* 07 GFP_DMA, GFP_DMA32 and GFP_DMA32 set */
> > > > > 	ZONE_MOVABLE,		/* 08 Only ZONE_MOVABLE set */
> > > > > 	ZONE_DMA,		/* 09 MOVABLE + DMA */
> > > > > 	ZONE_MOVABLE,		/* 0A MOVABLE + HIGHMEM */
> > > > > 	ZONE_DMA,		/* 0B MOVABLE + DMA + HIGHMEM */
> > > > > 	ZONE_DMA32,		/* 0C MOVABLE + DMA32 */
> > > > > 	ZONE_DMA,		/* 0D MOVABLE + DMA + DMA32 */
> > > > > 	ZONE_DMA32,		/* 0E MOVABLE + DMA32 + HIGHMEM */
> > > > > 	ZONE_DMA		/* 0F MOVABLE + DMA32 + HIGHMEM + DMA
> > > > > };
> > > > >
> > > > > Hmmmm... Guess one would need to add some #ifdeffery here to setup
> > > > > ZONE_NORMAL in cases there is no DMA, DMA32 and HIGHMEM.
> > > > >
> > > >
> > > > Indeed, as I said, this is somewhat error prone which is why the patch
> > > > calculates the table at run-time instead of compile-time trickery.
> > >
> > > One would need to define some macros to make it simpler I guess
> > >
> > > Write something like
> > >
> > > #ifdef CONFIG_ZONE_DMA
> > > #define TZONE_DMA ZONE_DMA
> > > #else
> > > #define TZONE_DMA ZONE_NORMAL
> > > #endif
> > >
> > > for each configurable item. Then just add the T to the above table.
> > >
> >
> > If you don't mind, I'd like to postpone writing such a patch until a second
> > or third pass at improving the allocator. I don't think I'll have the time
> > in the short-term to put together a const-initialised-table patch that will
> > definitily be correct.
> >
> > Alternatively, I can drop this patch entirely from the set.
> >
> >
> 
> Let me give it a shot:
> 
> Note that there is a slight buggyness in the current implementation of
> gfp_zone. If you set both GFP_DMA32 and GFP_HIGHMEM and the arch does not
> support GFP_DMA32 then gfp_zone returns GFP_HIGHMEM which may result in
> memory being allocated that cannot be used for I/O.
> 
> This version here returns GFP_NORMAL which is more correct.
> 
> 
> #ifdef CONFIG_ZONE_HIGHMEM
> #define OPT_ZONE_HIGHMEM ZONE_HIGHMEM
> #else
> #define OPT_ZONE_HIGHMEM ZONE_NORMAL
> #endif
> 
> #ifdef CONFIG_ZONE_DMA
> #define OPT_ZONE_DMA ZONE_DMA
> #else
> #define OPT_ZONE_DMA ZONE_NORMAL
> #endif
> 
> #ifdef CONFIG_ZONE_DMA32
> #define OPT_ZONE_DMA32 ZONE_DMA32
> #else
> #define OPT_ZONE_DMA32 OPT_ZONE_DMA
> #endif
> 
> 
> const int gfp_zone_table[GFP_ZONEMASK] = {
> 	ZONE_NORMAL,            /* 00 No flags set */
> 	OPT_ZONE_DMA,           /* 01 GFP_DMA */
> 	OPT_ZONE_HIGHMEM,       /* 02 GFP_HIGHMEM */
>         OPT_ZONE_DMA,           /* 03 GFP_HIGHMEM GFP_DMA */
>         OPT_ZONE_DMA32,         /* 04 GFP_DMA32 */
>         OPT_ZONE_DMA,           /* 05 GFP_DMA32 GFP_DMA */
>         OPT_ZONE_DMA32,         /* 06 GFP_DMA32 GFP_HIGHMEM */
>         OPT_ZONE_DMA,           /* 07 GFP_DMA32 GFP_HIGHMEM GFP_DMA */
>         ZONE_NORMAL,            /* 08 ZONE_MOVABLE */
>         OPT_ZONE_DMA,           /* 09 MOVABLE + DMA */
>         ZONE_MOVABLE,           /* 0A MOVABLE + HIGHMEM */
>         OPT_ZONE_DMA,           /* 0B MOVABLE + HIGHMEM + DMA */
>         OPT_ZONE_DMA32,         /* 0C MOVABLE + DMA32 */
>         OPT_ZONE_DMA,           /* 0D MOVABLE + DMA32 + DMA */
>         OPT_ZONE_DMA32,         /* 0E MOVABLE + DMA32 + HIGHMEM */
>         OPT_ZONE_DMA            /* 0F MOVABLE + DMA32 + HIGHMEM + DMA */
> };
> 

Thanks.At a quick glance, it looks ok but I haven't tested it. As the intention
was to get one pass of patches that are not controversial and are "obvious",
I have dropped my version of the gfp_zone patch and the subsequent flag
cleanup and will revisit it after the first lot of patches has been dealt
with. I'm testing again with the remaining patches.

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

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nick Piggin <npiggin@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lin Ming <ming.m.lin@intel.com>,
	Zhang Yanmin <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 24/27] Convert gfp_zone() to use a table of precalculated values
Date: Wed, 18 Mar 2009 18:17:17 +0000	[thread overview]
Message-ID: <20090318181717.GC24462@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.1.10.0903181300540.15570@qirst.com>

On Wed, Mar 18, 2009 at 01:21:30PM -0400, Christoph Lameter wrote:
> 
> 
> > time.
> >
> > > > > const int gfp_zone_table[GFP_ZONEMASK] = {
> > > > > 	ZONE_NORMAL,		/* 00 No flags set */
> > > > > 	ZONE_DMA,		/* 01 Only GFP_DMA set */
> > > > > 	ZONE_HIGHMEM,		/* 02 Only GFP_HIGHMEM set */
> > > > > 	ZONE_DMA,		/* 03 GFP_HIGHMEM and GFP_DMA set */
> > > > > 	ZONE_DMA32,		/* 04 Only GFP_DMA32 set */
> > > > > 	ZONE_DMA,		/* 05 GFP_DMA and GFP_DMA32 set */
> > > > > 	ZONE_DMA32,		/* 06 GFP_DMA32 and GFP_HIGHMEM set */
> > > > > 	ZONE_DMA,		/* 07 GFP_DMA, GFP_DMA32 and GFP_DMA32 set */
> > > > > 	ZONE_MOVABLE,		/* 08 Only ZONE_MOVABLE set */
> > > > > 	ZONE_DMA,		/* 09 MOVABLE + DMA */
> > > > > 	ZONE_MOVABLE,		/* 0A MOVABLE + HIGHMEM */
> > > > > 	ZONE_DMA,		/* 0B MOVABLE + DMA + HIGHMEM */
> > > > > 	ZONE_DMA32,		/* 0C MOVABLE + DMA32 */
> > > > > 	ZONE_DMA,		/* 0D MOVABLE + DMA + DMA32 */
> > > > > 	ZONE_DMA32,		/* 0E MOVABLE + DMA32 + HIGHMEM */
> > > > > 	ZONE_DMA		/* 0F MOVABLE + DMA32 + HIGHMEM + DMA
> > > > > };
> > > > >
> > > > > Hmmmm... Guess one would need to add some #ifdeffery here to setup
> > > > > ZONE_NORMAL in cases there is no DMA, DMA32 and HIGHMEM.
> > > > >
> > > >
> > > > Indeed, as I said, this is somewhat error prone which is why the patch
> > > > calculates the table at run-time instead of compile-time trickery.
> > >
> > > One would need to define some macros to make it simpler I guess
> > >
> > > Write something like
> > >
> > > #ifdef CONFIG_ZONE_DMA
> > > #define TZONE_DMA ZONE_DMA
> > > #else
> > > #define TZONE_DMA ZONE_NORMAL
> > > #endif
> > >
> > > for each configurable item. Then just add the T to the above table.
> > >
> >
> > If you don't mind, I'd like to postpone writing such a patch until a second
> > or third pass at improving the allocator. I don't think I'll have the time
> > in the short-term to put together a const-initialised-table patch that will
> > definitily be correct.
> >
> > Alternatively, I can drop this patch entirely from the set.
> >
> >
> 
> Let me give it a shot:
> 
> Note that there is a slight buggyness in the current implementation of
> gfp_zone. If you set both GFP_DMA32 and GFP_HIGHMEM and the arch does not
> support GFP_DMA32 then gfp_zone returns GFP_HIGHMEM which may result in
> memory being allocated that cannot be used for I/O.
> 
> This version here returns GFP_NORMAL which is more correct.
> 
> 
> #ifdef CONFIG_ZONE_HIGHMEM
> #define OPT_ZONE_HIGHMEM ZONE_HIGHMEM
> #else
> #define OPT_ZONE_HIGHMEM ZONE_NORMAL
> #endif
> 
> #ifdef CONFIG_ZONE_DMA
> #define OPT_ZONE_DMA ZONE_DMA
> #else
> #define OPT_ZONE_DMA ZONE_NORMAL
> #endif
> 
> #ifdef CONFIG_ZONE_DMA32
> #define OPT_ZONE_DMA32 ZONE_DMA32
> #else
> #define OPT_ZONE_DMA32 OPT_ZONE_DMA
> #endif
> 
> 
> const int gfp_zone_table[GFP_ZONEMASK] = {
> 	ZONE_NORMAL,            /* 00 No flags set */
> 	OPT_ZONE_DMA,           /* 01 GFP_DMA */
> 	OPT_ZONE_HIGHMEM,       /* 02 GFP_HIGHMEM */
>         OPT_ZONE_DMA,           /* 03 GFP_HIGHMEM GFP_DMA */
>         OPT_ZONE_DMA32,         /* 04 GFP_DMA32 */
>         OPT_ZONE_DMA,           /* 05 GFP_DMA32 GFP_DMA */
>         OPT_ZONE_DMA32,         /* 06 GFP_DMA32 GFP_HIGHMEM */
>         OPT_ZONE_DMA,           /* 07 GFP_DMA32 GFP_HIGHMEM GFP_DMA */
>         ZONE_NORMAL,            /* 08 ZONE_MOVABLE */
>         OPT_ZONE_DMA,           /* 09 MOVABLE + DMA */
>         ZONE_MOVABLE,           /* 0A MOVABLE + HIGHMEM */
>         OPT_ZONE_DMA,           /* 0B MOVABLE + HIGHMEM + DMA */
>         OPT_ZONE_DMA32,         /* 0C MOVABLE + DMA32 */
>         OPT_ZONE_DMA,           /* 0D MOVABLE + DMA32 + DMA */
>         OPT_ZONE_DMA32,         /* 0E MOVABLE + DMA32 + HIGHMEM */
>         OPT_ZONE_DMA            /* 0F MOVABLE + DMA32 + HIGHMEM + DMA */
> };
> 

Thanks.At a quick glance, it looks ok but I haven't tested it. As the intention
was to get one pass of patches that are not controversial and are "obvious",
I have dropped my version of the gfp_zone patch and the subsequent flag
cleanup and will revisit it after the first lot of patches has been dealt
with. I'm testing again with the remaining patches.

-- 
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:[~2009-03-18 18:17 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-16 17:53 [PATCH 00/26] Cleanup and optimise the page allocator V4 Mel Gorman
2009-03-16 17:53 ` Mel Gorman
2009-03-16 17:53 ` [PATCH 01/27] Replace __alloc_pages_internal() with __alloc_pages_nodemask() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 02/27] Do not sanity check order in the fast path Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 03/27] Do not check NUMA node ID when the caller knows the node is valid Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 04/27] Check only once if the zonelist is suitable for the allocation Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 05/27] Break up the allocator entry point into fast and slow paths Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 19:30   ` Christoph Lameter
2009-03-16 19:30     ` Christoph Lameter
2009-03-16 17:53 ` [PATCH 06/27] Move check for disabled anti-fragmentation out of fastpath Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 07/27] Check in advance if the zonelist needs additional filtering Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 08/27] Calculate the preferred zone for allocation only once Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 09/27] Calculate the migratetype " Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 10/27] Calculate the alloc_flags " Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 11/27] Calculate the cold parameter " Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 12/27] Remove a branch by assuming __GFP_HIGH == ALLOC_HIGH Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 13/27] Inline __rmqueue_smallest() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 18:55   ` Christoph Lameter
2009-03-16 18:55     ` Christoph Lameter
2009-03-16 17:53 ` [PATCH 14/27] Inline buffered_rmqueue() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 15/27] Inline __rmqueue_fallback() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 16/27] Save text by reducing call sites of __rmqueue() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 17/27] Do not call get_pageblock_migratetype() more than necessary Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 18/27] Do not disable interrupts in free_page_mlock() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 18:57   ` Christoph Lameter
2009-03-16 18:57     ` Christoph Lameter
2009-03-16 17:53 ` [PATCH 19/27] Do not setup zonelist cache when there is only one node Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 20/27] Use a pre-calculated value for num_online_nodes() Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 21/27] Do not check for compound pages during the page allocator sanity checks Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 22/27] Use allocation flags as an index to the zone watermark Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 23/27] Update NR_FREE_PAGES only as necessary Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 24/27] Convert gfp_zone() to use a table of precalculated values Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 19:12   ` Christoph Lameter
2009-03-16 19:12     ` Christoph Lameter
2009-03-18 13:52     ` Mel Gorman
2009-03-18 13:52       ` Mel Gorman
2009-03-18 14:15       ` Christoph Lameter
2009-03-18 14:15         ` Christoph Lameter
2009-03-18 15:35         ` Mel Gorman
2009-03-18 15:35           ` Mel Gorman
2009-03-18 17:21           ` Christoph Lameter
2009-03-18 17:21             ` Christoph Lameter
2009-03-18 18:17             ` Mel Gorman [this message]
2009-03-18 18:17               ` Mel Gorman
2009-03-18 19:07               ` Christoph Lameter
2009-03-18 19:07                 ` Christoph Lameter
2009-03-18 19:46                 ` Mel Gorman
2009-03-18 19:46                   ` Mel Gorman
2009-03-19  0:04                   ` KAMEZAWA Hiroyuki
2009-03-19  0:04                     ` KAMEZAWA Hiroyuki
2009-03-19 15:05                     ` Christoph Lameter
2009-03-19 15:05                       ` Christoph Lameter
2009-03-19 16:53                       ` Christoph Lameter
2009-03-19 16:53                         ` Christoph Lameter
2009-03-19 18:11                         ` Mel Gorman
2009-03-19 18:11                           ` Mel Gorman
2009-03-19 18:15                           ` Christoph Lameter
2009-03-19 18:15                             ` Christoph Lameter
2009-03-19 18:37                           ` Christoph Lameter
2009-03-19 18:37                             ` Christoph Lameter
2009-03-16 17:53 ` [PATCH 25/27] Re-sort GFP flags and fix whitespace alignment for easier reading Mel Gorman
2009-03-16 17:53   ` Mel Gorman
2009-03-16 17:53 ` [PATCH 26/27] Get the pageblock migratetype without disabling interrupts Mel Gorman
2009-03-16 17:53   ` 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=20090318181717.GC24462@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=cl@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ming.m.lin@intel.com \
    --cc=npiggin@suse.de \
    --cc=penberg@cs.helsinki.fi \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=yanmin_zhang@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.