From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: LinuxIA64 <linux-ia64@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC/PATCH] pfn_valid() more generic : arch independent part[0/2]
Date: Thu, 07 Oct 2004 00:10:44 +0000 [thread overview]
Message-ID: <41648984.1080904@jp.fujitsu.com> (raw)
In-Reply-To: <1209350000.1097075647@[10.10.2.4]>
Martin J. Bligh wrote:
>>This is generic parts.
>>
>>Boot-time routine:
>>At first, information of valid pages is gathered into a list.
>>After gathering all information, 2 level table are created.
>>Why I create table instead of using a list is only for good cache hit.
>>
>>pfn_valid_init() <- initilize some structures
>>validate_pages(start,size) <- gather valid pfn information
>>pfn_valid_setup() <- create 1st and 2nd table.
>
>
>
> Boggle. what on earth are you trying to do?
>
I just want to test whether a struct page for that pfn exists or not.
ia64 has holes in memmap in a zone, so ia64_pfn_valid() uses get_user() to test
whether a page struct exists or not.
In my no-bitmap buddy allocator, I must call pfn_valid() for ia64 at every loop
in free_pages_bulk()(in mm/page_alloc.c).
Beacause of holes in memmap, bad_range()(in mm/page_alloc.c) cannot work enough.
code will be like this:
while(...) {
pfn_of_buddy = some_func(pfn);
if( bad_range(pfn_of_buddy) )
break;
if( pfn_valid(pfn_of_buddy) ) <----- only for ia64.
this will disappear in other archs.
break;
....
}
Because pfn_valid() often returns 0 in inner loop of free_pages_bulk(),
I want to avoid page fault caused by using get_user() in pfn_valid().
I have 2 plan (1) modify pfn_valid or (2) modify bad_range().
this is plan(1).
In plan(2), 1st/2nd tables are attached to each zone/pgdat.
> pfn_valid does exactly one thing - it checks whether there is a struct
> page for that pfn. Nothing else. Surely that can't possibly take a tenth
> of this amount of code?
>
> M.
Kame <kamezawa.hiroyu@jp.fujitsu.com>
WARNING: multiple messages have this Message-ID (diff)
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: LinuxIA64 <linux-ia64@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC/PATCH] pfn_valid() more generic : arch independent part[0/2]
Date: Thu, 07 Oct 2004 09:10:44 +0900 [thread overview]
Message-ID: <41648984.1080904@jp.fujitsu.com> (raw)
In-Reply-To: <1209350000.1097075647@[10.10.2.4]>
Martin J. Bligh wrote:
>>This is generic parts.
>>
>>Boot-time routine:
>>At first, information of valid pages is gathered into a list.
>>After gathering all information, 2 level table are created.
>>Why I create table instead of using a list is only for good cache hit.
>>
>>pfn_valid_init() <- initilize some structures
>>validate_pages(start,size) <- gather valid pfn information
>>pfn_valid_setup() <- create 1st and 2nd table.
>
>
>
> Boggle. what on earth are you trying to do?
>
I just want to test whether a struct page for that pfn exists or not.
ia64 has holes in memmap in a zone, so ia64_pfn_valid() uses get_user() to test
whether a page struct exists or not.
In my no-bitmap buddy allocator, I must call pfn_valid() for ia64 at every loop
in free_pages_bulk()(in mm/page_alloc.c).
Beacause of holes in memmap, bad_range()(in mm/page_alloc.c) cannot work enough.
code will be like this:
while(...) {
pfn_of_buddy = some_func(pfn);
if( bad_range(pfn_of_buddy) )
break;
if( pfn_valid(pfn_of_buddy) ) <----- only for ia64.
this will disappear in other archs.
break;
....
}
Because pfn_valid() often returns 0 in inner loop of free_pages_bulk(),
I want to avoid page fault caused by using get_user() in pfn_valid().
I have 2 plan (1) modify pfn_valid or (2) modify bad_range().
this is plan(1).
In plan(2), 1st/2nd tables are attached to each zone/pgdat.
> pfn_valid does exactly one thing - it checks whether there is a struct
> page for that pfn. Nothing else. Surely that can't possibly take a tenth
> of this amount of code?
>
> M.
Kame <kamezawa.hiroyu@jp.fujitsu.com>
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-10-07 0:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 6:20 [RFC/PATCH] pfn_valid() more generic : intro[0/2] Hiroyuki KAMEZAWA
2004-10-06 6:20 ` Hiroyuki KAMEZAWA
2004-10-06 6:33 ` Luck, Tony
2004-10-06 6:33 ` Luck, Tony
2004-10-06 7:33 ` Hiroyuki KAMEZAWA
2004-10-06 7:33 ` Hiroyuki KAMEZAWA
2004-10-06 6:37 ` [RFC/PATCH] pfn_valid() more generic : arch independent part[0/2] Hiroyuki KAMEZAWA
2004-10-06 6:37 ` Hiroyuki KAMEZAWA
2004-10-06 15:14 ` Martin J. Bligh
2004-10-06 15:14 ` Martin J. Bligh
2004-10-07 0:10 ` Hiroyuki KAMEZAWA [this message]
2004-10-07 0:10 ` Hiroyuki KAMEZAWA
2004-10-07 5:22 ` Luck, Tony
2004-10-07 5:22 ` Luck, Tony
2004-10-07 6:28 ` Hiroyuki KAMEZAWA
2004-10-07 6:28 ` Hiroyuki KAMEZAWA
2004-10-07 6:51 ` align vmemmap to ia64's granule Hiroyuki KAMEZAWA
2004-10-07 14:38 ` [RFC/PATCH] pfn_valid() more generic : arch independent part[0/2] Martin J. Bligh
2004-10-07 14:38 ` Martin J. Bligh
2004-10-07 23:38 ` Hiroyuki KAMEZAWA
2004-10-07 23:38 ` Hiroyuki KAMEZAWA
2004-10-07 15:53 ` Luck, Tony
2004-10-07 15:53 ` Luck, Tony
2004-10-07 16:02 ` Martin J. Bligh
2004-10-07 16:02 ` Martin J. Bligh
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=41648984.1080904@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.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.