All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andy Whitcroft <apw@shadowen.org>, Mel Gorman <mel@csn.ul.ie>,
	Bob Picco <bob.picco@hp.com>, Dave Hansen <hansendc@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] add pfn_valid_within helper for sub-MAX_ORDER hole detection
Date: Wed, 21 Mar 2007 16:46:33 -0700	[thread overview]
Message-ID: <20070321164633.fa90d959.akpm@linux-foundation.org> (raw)
In-Reply-To: <4601BE6F.3000003@yahoo.com.au>

On Thu, 22 Mar 2007 10:23:27 +1100
Nick Piggin <nickpiggin@yahoo.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.

  reply	other threads:[~2007-03-21 23:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.64.0703211510340.15309@skynet.skynet.ie>
2007-03-21 19:14 ` [PATCH 0/3] pfn_valid_within() HOLES_WITHIN_ZONES helper Andy Whitcroft
2007-03-21 19:15   ` [PATCH 1/3] add pfn_valid_within helper for sub-MAX_ORDER hole detection Andy Whitcroft
2007-03-21 23:23     ` Nick Piggin
2007-03-21 23:46       ` Andrew Morton [this message]
2007-03-21 19:15   ` [PATCH 2/3] anti-fragmentation: switch over to pfn_valid_within() Andy Whitcroft
2007-03-21 19:16   ` [PATCH 3/3] lumpy: move to using pfn_valid_within() Andy Whitcroft
2007-03-21 20:55   ` [PATCH 0/3] pfn_valid_within() HOLES_WITHIN_ZONES helper Bob Picco

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=20070321164633.fa90d959.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=bob.picco@hp.com \
    --cc=hansendc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=nickpiggin@yahoo.com.au \
    /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.