From: Yasunori Goto <ygoto@us.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
Linux Hotplug Memory Support <lhms-devel@lists.sourceforge.net>,
Linux-Node-Hotplug <lhns-devel@lists.sourceforge.net>,
linux-mm <linux-mm@kvack.org>,
"BRADLEY CHRISTIANSEN [imap]" <bradc1@us.ibm.com>
Subject: Re: [Lhns-devel] Merging Nonlinear and Numa style memory hotplug
Date: Wed, 23 Jun 2004 20:04:48 -0700 [thread overview]
Message-ID: <20040623184303.25D9.YGOTO@us.fujitsu.com> (raw)
In-Reply-To: <1088029973.28102.269.camel@nighthawk>
> This quadruples the size of the mem_section[] array, and makes each
> mem_section entry take up a whole cache line. Are you sure all of these
> structure members are needed?
No, I'm not sure. Especially, I don't find whether hotremovable
attribute is necessary or not in the mem_section yet.
> Can they be allocated elsewhere, instead
> of directly inside the translation tables, or otherwise derived? Also,
> why does the booked/free_count have to be kept here? Can't that be
> determined by simply looping through and looking at all the pages'
> flags?
It might be OK. But there might be some other influence by it
(for example, new lock will be necessary in alloc_pages()...).
I think measurement is necessary to find which implementation
is the fastest. If I will have a time, I would like to try it.
> Also, can you provide a patch which is just your modifications to Dave's
> original nonlinear patch?
No, I don't have it (at least now).
Base of my patches is Iwamoto-san's patch which is for 2.6.5.
But Dave-san's patch is for linux-2.6.5-mm. So, I had to change
Dave-san's patch for it.
And, other difference thing is about mem_map.
Dave-san's patch divides virtual address of mem_map per mem_section.
But it is cause of increasing steps at 'buddy allocator' like this.
- buddy1 = base + (page_idx ^ -mask);
- buddy2 = base + page_idx;
+ buddy1 = pfn_to_page(base + (page_idx ^ -mask);
+ buddy2 = pfn_to_page(base + page_idx);
So, I would like to try contiguous virtual mem_map yet,
if it is possible.
> Instead of remove_from_freelist(unsigned int section), I'd hope that we
> could support a much more generic interface in the page allocator:
> allocate by physical address. remove_from_freelist() has some intimate
> knowledge of the buddy allocator that I think is a bit complex.
I don't think I understand your idea at this point.
If booked pages remain in free_list, page allocator has to
search many pages which include booked pages.
remove_from_reelist() is to avoid this.
Thank you for your responce.
Bye.
--
Yasunori Goto <ygoto at us.fujitsu.com>
WARNING: multiple messages have this Message-ID (diff)
From: Yasunori Goto <ygoto@us.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
Linux Hotplug Memory Support <lhms-devel@lists.sourceforge.net>,
Linux-Node-Hotplug <lhns-devel@lists.sourceforge.net>,
linux-mm <linux-mm@kvack.org>,
"BRADLEY CHRISTIANSEN [imap]" <bradc1@us.ibm.com>
Subject: Re: [Lhns-devel] Merging Nonlinear and Numa style memory hotplug
Date: Wed, 23 Jun 2004 20:04:48 -0700 [thread overview]
Message-ID: <20040623184303.25D9.YGOTO@us.fujitsu.com> (raw)
In-Reply-To: <1088029973.28102.269.camel@nighthawk>
> This quadruples the size of the mem_section[] array, and makes each
> mem_section entry take up a whole cache line. Are you sure all of these
> structure members are needed?
No, I'm not sure. Especially, I don't find whether hotremovable
attribute is necessary or not in the mem_section yet.
> Can they be allocated elsewhere, instead
> of directly inside the translation tables, or otherwise derived? Also,
> why does the booked/free_count have to be kept here? Can't that be
> determined by simply looping through and looking at all the pages'
> flags?
It might be OK. But there might be some other influence by it
(for example, new lock will be necessary in alloc_pages()...).
I think measurement is necessary to find which implementation
is the fastest. If I will have a time, I would like to try it.
> Also, can you provide a patch which is just your modifications to Dave's
> original nonlinear patch?
No, I don't have it (at least now).
Base of my patches is Iwamoto-san's patch which is for 2.6.5.
But Dave-san's patch is for linux-2.6.5-mm. So, I had to change
Dave-san's patch for it.
And, other difference thing is about mem_map.
Dave-san's patch divides virtual address of mem_map per mem_section.
But it is cause of increasing steps at 'buddy allocator' like this.
- buddy1 = base + (page_idx ^ -mask);
- buddy2 = base + page_idx;
+ buddy1 = pfn_to_page(base + (page_idx ^ -mask);
+ buddy2 = pfn_to_page(base + page_idx);
So, I would like to try contiguous virtual mem_map yet,
if it is possible.
> Instead of remove_from_freelist(unsigned int section), I'd hope that we
> could support a much more generic interface in the page allocator:
> allocate by physical address. remove_from_freelist() has some intimate
> knowledge of the buddy allocator that I think is a bit complex.
I don't think I understand your idea at this point.
If booked pages remain in free_list, page allocator has to
search many pages which include booked pages.
remove_from_reelist() is to avoid this.
Thank you for your responce.
Bye.
--
Yasunori Goto <ygoto at us.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-06-24 3:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-22 19:00 Merging Nonlinear and Numa style memory hotplug Yasunori Goto
2004-06-22 19:00 ` Yasunori Goto
2004-06-23 22:32 ` [Lhns-devel] " Dave Hansen
2004-06-23 22:32 ` Dave Hansen
2004-06-24 3:04 ` Yasunori Goto [this message]
2004-06-24 3:04 ` Yasunori Goto
2004-06-24 3:26 ` Dave Hansen
2004-06-24 3:26 ` Dave Hansen
2004-06-24 13:28 ` [Lhms-devel] " Dave Hansen
2004-06-24 13:28 ` Dave Hansen
2004-06-24 22:19 ` Yasunori Goto
2004-06-24 22:19 ` Yasunori Goto
2004-06-24 22:37 ` Dave Hansen
2004-06-24 22:37 ` Dave Hansen
2004-06-25 3:11 ` [Lhms-devel] " Yasunori Goto
2004-06-25 3:11 ` Yasunori Goto
2004-06-25 3:19 ` Dave Hansen
2004-06-25 3:19 ` Dave Hansen
2004-06-25 18:48 ` Yasunori Goto
2004-06-25 18:48 ` Yasunori Goto
2004-06-25 18:59 ` Dave Hansen
2004-06-25 18:59 ` Dave Hansen
2004-06-25 20:45 ` Yasunori Goto
2004-06-25 20:45 ` Yasunori Goto
2004-06-25 20:49 ` Dave Hansen
2004-06-25 20:49 ` Dave Hansen
2004-06-25 20:54 ` Dave Hansen
2004-06-25 20:54 ` Dave Hansen
2004-06-25 4:49 ` [Lhms-devel] Re: [Lhns-devel] " Shai Fultheim
2004-06-25 4:49 ` Shai Fultheim
2004-06-25 15:16 ` Dave Hansen
2004-06-25 15:16 ` Dave Hansen
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=20040623184303.25D9.YGOTO@us.fujitsu.com \
--to=ygoto@us.fujitsu.com \
--cc=bradc1@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=lhns-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--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.