From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
lhms <lhms-devel@lists.sourceforge.net>,
William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]
Date: Fri, 27 Aug 2004 09:42:05 +0900 [thread overview]
Message-ID: <412E835D.8080500@jp.fujitsu.com> (raw)
In-Reply-To: <1093565707.2984.394.camel@nighthawk>
Dave Hansen wrote:
>>1. Now, I think some small parts, some essence of mem_section which
>> makes pfn_valid() faster may be good.
>
>
> The only question is what it will take when there's a partially populate
> mem_section. We'll almost certainly have to allow it, but the real
> question is whether or not we will ever have a partially populated one
> that's not at the end of memory.
>
Hmm....I cannot answer it fully.
My tiger4 (Itanium x 2) shows aligned_order=0, because it has a mem_map
start with address 0x????????3(I forget now), odd number ;(.
I like a mechine in which all memory are aligned.....
>>And another way,
>>
>>2. A method which enables page -> page's max_order calculation
>> may be good and consistent way in this no-bitmap approach.
>>
>>But this problem would be my week-end homework :).
>
>
> Instead of adding more stuff to the mem_section, we might be able to
> (ab)use more stuff in the mem_map's mem_map, like I am with
> page->section right now.
I wonder if there is another way which doesn't increase memory usage
in boottime, it will be better.
I'll going on considering the way to fix nr_mem_map things.
Thanks
-- Kame
--
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
WARNING: multiple messages have this Message-ID (diff)
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
lhms <lhms-devel@lists.sourceforge.net>,
William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]
Date: Fri, 27 Aug 2004 09:42:05 +0900 [thread overview]
Message-ID: <412E835D.8080500@jp.fujitsu.com> (raw)
In-Reply-To: <1093565707.2984.394.camel@nighthawk>
Dave Hansen wrote:
>>1. Now, I think some small parts, some essence of mem_section which
>> makes pfn_valid() faster may be good.
>
>
> The only question is what it will take when there's a partially populate
> mem_section. We'll almost certainly have to allow it, but the real
> question is whether or not we will ever have a partially populated one
> that's not at the end of memory.
>
Hmm....I cannot answer it fully.
My tiger4 (Itanium x 2) shows aligned_order=0, because it has a mem_map
start with address 0x????????3(I forget now), odd number ;(.
I like a mechine in which all memory are aligned.....
>>And another way,
>>
>>2. A method which enables page -> page's max_order calculation
>> may be good and consistent way in this no-bitmap approach.
>>
>>But this problem would be my week-end homework :).
>
>
> Instead of adding more stuff to the mem_section, we might be able to
> (ab)use more stuff in the mem_map's mem_map, like I am with
> page->section right now.
I wonder if there is another way which doesn't increase memory usage
in boottime, it will be better.
I'll going on considering the way to fix nr_mem_map things.
Thanks
-- Kame
--
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <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-08-27 0:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-26 12:10 [RFC] buddy allocator without bitmap [3/4] Hiroyuki KAMEZAWA
2004-08-26 12:10 ` Hiroyuki KAMEZAWA
2004-08-26 15:55 ` Dave Hansen
2004-08-26 15:55 ` Dave Hansen
2004-08-27 0:05 ` [Lhms-devel] " Hiroyuki KAMEZAWA
2004-08-27 0:05 ` Hiroyuki KAMEZAWA
2004-08-27 0:15 ` Dave Hansen
2004-08-27 0:15 ` Dave Hansen
2004-08-27 0:42 ` Hiroyuki KAMEZAWA [this message]
2004-08-27 0:42 ` Hiroyuki KAMEZAWA
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=412E835D.8080500@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=haveblue@us.ibm.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.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.