linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: linux-mm <linux-mm@kvack.org>
Cc: LHMS <lhms-devel@lists.sourceforge.net>
Subject: [RFC]  free_area[]  bitmap elimination [0/3]
Date: Sat, 21 Aug 2004 11:31:21 +0900	[thread overview]
Message-ID: <4126B3F9.90706@jp.fujitsu.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

Hi

This patch removes bitmap from buddy allocator used in
alloc_pages()/free_pages() in the kernel 2.6.8.1.

Currently, Linux's page allocator uses bitmaps to record an order
of a free page.
This patch removes bitmap from buddy allocator, and uses
page->private field to record an order of a page.

My purpose is to reduce complexity of buddy allocator, when we want to
hotplug memory. For memory hotplug, we have to resize memory management
structures. Major two of them are mem_map and bitmap.If this patch removes
bitmap from buddy allocator, resizeing bitmap will be needless.

I tested this patch on my small PC box(Celeron900MHz,256MB memory)
and a server machine(Xeon x 2, 4GB memory).

Patch is divided into 4 parts
p01 .....  for include files
p02 .....  for initialization of zone
p03 .....  for alloc_pages()
p04 .....  for free_pages()

Note:
This patch records an order of a page in page->private field, in
page->private = ~order manner.
This is because there are pages which is not in buddy allocator and is its
page_count(page)==0.

I'm not convinced that page->private is not used while page_count(page) == 0.
If used, this patch will have a problem.

Thanks
KAME

-- 
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>


[-- Attachment #2: eliminate-bitmap-p01.patch --]
[-- Type: text/x-patch, Size: 1991 bytes --]


Eliminate free_area_t bitmap patches.
p01 is for include files.


---

 linux-2.6.8.1-kame-kamezawa/include/linux/mm.h     |   16 ++++++++++++++--
 linux-2.6.8.1-kame-kamezawa/include/linux/mmzone.h |    1 -
 2 files changed, 14 insertions(+), 3 deletions(-)

diff -puN include/linux/mmzone.h~eliminate-bitmap-p01 include/linux/mmzone.h
--- linux-2.6.8.1-kame/include/linux/mmzone.h~eliminate-bitmap-p01	2004-08-19 13:16:05.000000000 +0900
+++ linux-2.6.8.1-kame-kamezawa/include/linux/mmzone.h	2004-08-19 13:34:34.000000000 +0900
@@ -34,7 +34,6 @@
 
 struct free_area {
 	struct list_head	free_list;
-	unsigned long		*map;
 };
 
 struct pglist_data;
diff -puN include/linux/mm.h~eliminate-bitmap-p01 include/linux/mm.h
--- linux-2.6.8.1-kame/include/linux/mm.h~eliminate-bitmap-p01	2004-08-19 13:22:24.000000000 +0900
+++ linux-2.6.8.1-kame-kamezawa/include/linux/mm.h	2004-08-21 08:52:59.137598728 +0900
@@ -203,8 +203,9 @@ struct page {
 	unsigned long private;		/* Mapping-private opaque data:
 					 * usually used for buffer_heads
 					 * if PagePrivate set; used for
-					 * swp_entry_t if PageSwapCache
-					 */
+					 * swp_entry_t if PageSwapCache.
+					 * when page is free, this field
+					 * keeps order of page. */
 	struct address_space *mapping;	/* If PG_anon clear, points to
 					 * inode address_space, or NULL.
 					 * If page mapped as anonymous
@@ -313,9 +314,20 @@ static inline void put_page(struct page 
 		__page_cache_release(page);
 }
 
+
+
+
 #endif		/* CONFIG_HUGETLB_PAGE */
 
 /*
+ *	indicates page's order in freelist
+ *      order is recorded in inveterd manner.
+ */
+#define page_order(page)	(~((page)->private))
+#define set_page_order(page,order)	((page)->private = ~order)
+#define invalidate_page_order(page) ((page)->private = 0)
+
+/*
  * Multiple processes may "see" the same page. E.g. for untouched
  * mappings of /dev/null, all processes see the same page full of
  * zeroes, and text pages of executables and shared libraries have

_

             reply	other threads:[~2004-08-21  2:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-21  2:31 Hiroyuki KAMEZAWA [this message]
2004-08-21  2:55 ` William Lee Irwin III
2004-08-21  4:56   ` [Lhms-devel] " Hirokazu Takahashi
2004-08-21  5:21     ` William Lee Irwin III
2004-08-21  5:37       ` Hiroyuki KAMEZAWA
2004-08-21  5:37         ` William Lee Irwin III
2004-08-21  6:10           ` Hiroyuki KAMEZAWA
2004-08-21 17:48             ` William Lee Irwin III
2004-08-21  5:00   ` Hiroyuki KAMEZAWA
2004-08-21  5:01     ` [Lhms-devel] " Hirokazu Takahashi
2004-08-21  5:26       ` Hiroyuki KAMEZAWA
2004-08-21  5:01     ` William Lee Irwin III
2004-08-21  9:43 ` Nigel Cunningham
2004-08-23 14:36 ` [Lhms-devel] " Dave Hansen
2004-08-23 15:00   ` Dave Hansen
2004-08-24  0:07     ` [Lhms-devel] " Hiroyuki KAMEZAWA
2004-08-24  0:00   ` [Lhms-devel] " Hiroyuki KAMEZAWA
2004-08-24  2:28     ` Hirokazu Takahashi
2004-08-24  2:49     ` Dave Hansen
2004-08-24  3:31       ` Hiroyuki KAMEZAWA
2004-08-23 15:43 ` Dave Hansen
2004-08-24  0:15   ` 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=4126B3F9.90706@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox