From: Dave Hansen <haveblue@us.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC] memory-layout-free zones (for review) [3/3] fix for_each_page_in_zone
Date: Thu, 23 Feb 2006 10:12:13 -0800 [thread overview]
Message-ID: <1140718333.8697.69.camel@localhost.localdomain> (raw)
In-Reply-To: <20060223180023.396d2cfe.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 2006-02-23 at 18:00 +0900, KAMEZAWA Hiroyuki wrote:
> +static inline struct page *first_page_in_zone(struct zone *zone)
> +{
> + struct pglist_data *pgdat;
> + unsigned long start_pfn;
> + unsigned long i = 0;
> +
> + if (!populated_zone(zone))
> + return NULL;
> +
> + pgdat = zone->zone_pgdat;
> + zone = pgdat->node_start_pfn;
> +
> + for (i = 0; i < pgdat->zone_spanned_pages; i++) {
> + if (pfn_valid(start_pfn + i) && page_zone(page) == zone)
> + break;
> + }
> + BUG_ON(i == pgdat->node_spanned_pages); /* zone is populated */
> + return pfn_to_page(start_pfn + i);
> +}
I know we don't use this function _too_ much , but it would probably be
nice to make it a little smarter than "i++". We can be pretty sure, at
least with SPARSEMEM that the granularity is larger than that. We can
probably leave it until it gets to be a real problem.
I was also trying to think if a binary search is appropriate here. I
guess it depends on whether we allow the zones to have overlapping pfn
ranges, which I _think_ is one of the goals from these patches. Any
thoughts?
Oh, and I noticed the "pgdat->zone_spanned_pages" bit. Did you compile
this? ;)
> +static inline struct page *next_page_in_zone(struct page *page,
> + struct zone *zone)
> +{
> + struct pglist_data *pgdat;
> + unsigned long start_pfn;
> + unsigned long i;
> +
> + if (!populated_zone(zone))
> + return NULL;
> + pgdat = zone->zone_pgdat;
> + start_pfn = pgdat->node_start_pfn;
> + i = page_to_pfn(page) - start_pfn;
> +
> + for (i = i + 1; i < pgdat->node_spanned_pages; i++) {
> + if (pfn_vlaid(start_pfn + i) && page_zone(page) == zone)
> + break;
> + }
> + if (i == pgdat->node_spanned_pages)
> + return NULL;
> + return pfn_to_page(start_pfn + i);
> +}
Same comment, BTW, about code sharing. Is it something we want to or
can do with these?
-- Dave
--
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:[~2006-02-23 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 9:00 [RFC] memory-layout-free zones (for review) [3/3] fix for_each_page_in_zone KAMEZAWA Hiroyuki
2006-02-23 18:12 ` Dave Hansen [this message]
2006-02-24 0:03 ` KAMEZAWA Hiroyuki
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=1140718333.8697.69.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
/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.