All of lore.kernel.org
 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 ` [RFC] free_area[] bitmap elimination [0/3] 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 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.