[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20070321164633.fa90d959.akpm@linux-foundation.org>
Date: Wed, 21 Mar 2007 16:46:33 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Andy Whitcroft <apw@...dowen.org>, Mel Gorman <mel@....ul.ie>,
Bob Picco <bob.picco@...com>,
Dave Hansen <hansendc@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] add pfn_valid_within helper for sub-MAX_ORDER hole
detection
On Thu, 22 Mar 2007 10:23:27 +1100
Nick Piggin <nickpiggin@...oo.com.au> wrote:
> Andy Whitcroft wrote:
> > Generally we work under the assumption that memory the mem_map
> > array is contigious and valid out to MAX_ORDER_NR_PAGES block
> > of pages, ie. that if we have validated any page within this
> > MAX_ORDER_NR_PAGES block we need not check any other. This is not
> > true when CONFIG_HOLES_IN_ZONE is set and we must check each and
> > every reference we make from a pfn.
> >
> > Add a pfn_valid_within() helper which should be used when scanning
> > pages within a MAX_ORDER_NR_PAGES block when we have already
> > checked the validility of the block normally with pfn_valid().
> > This can then be optimised away when we do not have holes within
> > a MAX_ORDER_NR_PAGES block of pages.
>
> Nice cleanup. Horrible name ;) Calls read like "is the pfn valid
> within pfn".
yeah
> I can't think of anything really good, but I think, say,
> pfn_valid_within_block or pfn_valid_within_valid_block would be a
> bit better. You still get a slight net savings in keystrokes!
Neither of those identifiers seem to really fit, and I can't think of anything
suitable either. Oh well, at least pfn_valid_within() has a nice comment
explaining what it does.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists