From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.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: Fri, 24 Feb 2006 09:03:17 +0900 [thread overview]
Message-ID: <43FE4D45.2040209@jp.fujitsu.com> (raw)
In-Reply-To: <1140718333.8697.69.camel@localhost.localdomain>
Dave Hansen wrote:
> 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.
Yes, SPARSEMEM can skip PAGES_PER_SECTION pages if !pfn_valid()
>
> 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?
>
What I'm thinking of is to allow zones to have overlapping pfn ranges.
Showing benefit of it (by patch) is difficult now but I think it's sane
direction.
> Oh, and I noticed the "pgdat->zone_spanned_pages" bit. Did you compile
> this? ;)
>
No (>_<
>> +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?
>
Hmm...I can't find it. I'll rewrite this code as out-of-line function and
add optimizaion by its memory_model, and do more cleanup.
I'll post these again to -mm before going lkml, and will do compile them in
the next time....
-- Kame
--
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>
prev parent reply other threads:[~2006-02-24 0:03 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
2006-02-24 0:03 ` KAMEZAWA Hiroyuki [this message]
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=43FE4D45.2040209@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=haveblue@us.ibm.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.